Success in the Cloud: A TLC Customer Interview

Success in the Cloud: A TLC Customer Interview

“You know, obviously, this is going to be more difficult,” begins Matthew Mattson at the start of his interview with Jamison Reynolds (Director of Marketing) and Rhia Stark (Digital Engagement Manager) of The Library Corporation (TLC). “Because I’ve been on CARL a lot longer than I’ve been on the Oracle platform,” he finishes with a laugh.

As a long-standing user of the CARLX integrated library system, and with responsibility over Web Technologies at Los Angeles Public Library (LAPL), Matthew is used to being a reference for the CARL ILS but has only been in a hosted environment since February 2020.

The three have gathered remotely to discuss LAPL’s transition from an on-premise environment to hosting through TLCCloud Services, powered by Oracle Cloud Infrastructure (OCI). Matthew shares how the library planned for this momentous move, how to expect the unexpected, and what other libraries can gain from life in the cloud.

Some content has been edited for clarity and consistency.

Moving 27+ Years of Data Into the Cloud

Los Angeles Public Library has been a CARL customer since 1993, with local servers out of the Central Library that entire time. Tell us about the plan to switch to a hosted environment.

We’d always been on-premises, and we were scheduled to go hosted in the Fall to the previous host.

You were prepared to make this move into TLC’s previous hosted environment before we selected to move forward with OCI. What happened next?

We postponed. We understood the reasoning and the logic was sound, but we didn’t want to be the first due to our size. So we waited until Somerset moved to Oracle. When TLC had that one completed, then we went next.

After the delay and the pivot toward OCI, how did the implementation go? What was your overall perception of the process?

In all honesty, we had a little bit of an advantage of having been stopped late in the previous move, that we had a lot of our checklist already completed. Now granted, we had to go back and redo things with new addresses and stuff, but it was almost like we had a trial run of almost moving to the other one. So we kind of had to restart the process, but the advantage of it was that we’d already thought of most of the things that we needed to do and so we were very confident in our checklist of moving to the Oracle platform because all the things that we were thinking about previously, they were already on our list.

What were some of the items on your checklist?

Our biggest thing was all twenty-seven years’ worth of stuff that we’ve put in that we suddenly had to start thinking about again. We have Ad Hoc Reports that aren’t just talking to the quote unquote “CARL database.” They’re talking to a bunch of different stuff. And vendors! All the vendors who either run our client or SIP2.

Most of our checklist was not: does it checkout a book?. I mean, that was very quickly: Yup — the CARL client works as we expect. Moving on now. What about these literally eighty-seven different Ad Hoc Reports we’re running that are talking to a bunch of different stuff? Do we even know where all of them are running these days? And all the scripts we have to change?

So we had to think about everything that we’ve ever set up in twenty-seven years that was used to talking to ourselves that now had to talk to someplace else. That was really what was most of our time was just trying to make sure that we thought of all that stuff.

If we could zoom out for a second, let’s put this into a percentage chart. If you’re thinking about the active time that went into the OCI migration, what percent of that was re-thinking about processes that had to happen? What percent of that was testing? And what percent of that was smooth sailing after go-live?

In planning, I would say 80% of it was trying to think of all of these things: Who do we have to talk to, what needs to be changed, who has to know the new address, who has to talk through the VPN tunnel, and who can go public. That was a new thing for us: the fact that there was a public and a private address, and that you had to know who you wanted to route through the tunnel versus what could go through the public.

In terms of planning, that was absolutely the biggest chunk. If you do that part right, once you move, it’s all good.

Quite honestly, we didn’t really concern ourselves with the functionality testing in that way. Maybe we should have more, but in general as long as your connection’s there, it’s going to work. CARL didn’t suddenly switch how it works; it’s just talking to a different endpoint.

The rest was more, What does the staff need to know?

View from the Cloud

Can you compare the performance of CARLX while locally hosted to the performance after the implementation and after some of the configurations were finalized?

We haven’t noticed any problems, any issues. If the staff members didn’t know we moved, I don’t think any of them would tell you that anything changed in terms of the Client performance. If you’re at a Circ desk, there is absolutely no difference from when they were talking to Central Library versus when they’re talking to wherever the hosted facility is.

And part of that is because we actually reduced the amount of traffic on our own network. All the public that’s accessing the catalog and the SIP2 clients and everything, that’s not going through us anymore. That’s going directly to the hosted facility.

As big as we are, any traffic that’s not on our network is good! Because we’re always running at capacity on our network, anything that we could offload like that was great. Now obviously all the staff communication is still going through the VPN and that’s going through our firewall. But I got two hundred people at a time on my catalog in peak hours, and they’re not using my network anymore!

The other thing that the hosted facility does for us is that not only does it make maintenance easier in the terms that we don’t have to be a part of it (it used to be that someone had to be on-call in case they needed physical access), but it has speeded up. When we do our quarterly updates, just the fact that the hosted facility has so much bigger pipe and bigger servers, we’ve gone from being down for like six hours for the updates to less than two.

There is no time during a twenty four hour, seven day, three-hundred-sixty-five days a year that someone isn’t using our system. So obviously the less down time we have, the better. For a place like us, that’s important because every time we’re down, we hear about it.

How has your staff adapted to the hosted environment?

TLC was primarily responsible for the servers themselves in terms of doing the quarterly updates and stuff, but the servers were here and that does entail staff time. If there was a problem, first of all, we had to determine: Is it us? Is it our network? What’s going on? And then even if it was the server: Is it something that we can do locally?

Obviously there is a tremendous amount of staff time that isn’t concerned anymore with the CARL system. And it’s not that they’re now sitting around twiddling their thumbs because, believe me, they have plenty of other stuff that’s requiring their attention.We run probably a good twenty-five dedicated servers that are doing various things.

So the fact that we don’t have eight more of them to worry about is a good thing.

Can you quantify the amount of staff time saved in hours per week?

I don’t know that I could because it wasn’t a consistent thing. We might go weeks that we don’t really have anything, but then we might have staff have to devote a significant amount of time to working with CARL to do whatever. So it’s very hard to quantify that but even if I can’t put a number on it, it is just one thing we don’t have to think about anymore. We don’t have to worry about it.

Only thing that we have to maintain is that VPN tunnel and basically once we got it right, there’s no maintenance involved in that. It’s just there. It’s not like a server or anything; it’s just a configuration on the firewall. It doesn’t change. You don’t have to do anything to it. You don’t have to update it. You don’t have to babysit it. It’s just there.

We just don’t have any staff time, in that kind of a sense, making sure that people can get to the CARL system.

Advice for Other Libraries

What advice can you share for other libraries considering moving to a hosted environment?

Do a complete inventory of your processes.

Because, like I said, it’s just so easy to forget about something that’s just been sitting there doing stuff for ten years. It’s not enough just to say, “Oh well, it’s the CARL system. Here’s all of the stuff that’s the CARL system.” Because I guarantee you, if you’re a library that’s been running it for a significant amount of time, you’ve got stuff that you’ve forgotten about that is touching the CARL system in some way. Whether it’s Reports, whether it is a vendor, whether it is how you’re doing authentication for some of your databases.

You’ve got something out there that just is not on your day-to-day radar, and so you really do need to do a complete, thorough inventory of your system to see what all really is touching your ILS system. Because it’s more than you think it is. Like I said, if you do that part right, once you move, it’s all good.

It just becomes so much less of a concern on your part because everything is now in OCI’s hands. This is what they do. They’re better at security than you are. They’re better at uptime than you are. Just because that’s their business. As good as any library is in its IT department, they’re not going to compete with a professional hosting service for all of those intangibles and all of those tangibles.

That’s something that you just are freed from. And as long as you get it right in the planning, once you make the move, things become very easy.


For more information, visit



Justin Larsen Larsen