Retiring a Database Older Than I Am

Have you ever tried to put away a pile of laundry that’s been growing for weeks? You know it needs to be done, yet you avoid it for as long as possible. Now imagine that pile started 30 years ago, contains data spread across dozens of systems, and has hundreds of people unknowingly relying on it every single day. That’s what it feels like to retire a legacy database.

Earlier this year I had the opportunity to help one of our clients retire an on-premises database older than I am. The 30-year-old database had been seen as outdated for at least 10 years, but it was still actively being used. Here are some of the things I heard when I started the project:

Our client is a national restaurant chain with thousands of employees. My team’s original assignment was to help migrate one slice of their data off of this legacy system. But after engaging in project conversations, we became central to a much larger cloud migration initiative.

This database was being used everywhere. It supported business intelligence (BI) reports, sent files across the enterprise, and quietly powered analyses across labor, finance, operations, and more. No one at the company had a complete picture of it, especially because of how poorly documented it was.

There was a sense of unease that by turning off the database, mission-critical processes would break. Retiring the database required more than a migration—it required intentional change management for a tangled web of teams and tools.

So how did we actually pull it off?

Step 1: Understand the Impact

On these kinds of projects, scope is often unpredictable. For example, we discovered early on that there was another heavily used database that was tightly coupled with the first. Retiring one would bring down the other. I quickly organized a meeting with IT and analytics leaders, and they decided to retire both databases together. Thus, the scope effectively doubled.

To get a handle on what these two systems touched, we partnered with platform admins to find as many audit logs as we could get our hands on and reverse-engineered who was using the data. Hundreds of users were uncovered in this process. We defined tiers of criticality ranging from tables and pipelines to users who check a number once in a while. An important step was thoroughly documenting each of these in the same place.

What we found painted a clear picture: retiring these databases would require coordination across all corners of the business.

Step 2: Create Transition Resources

To prevent chaos, we had to provide clarity. I created a one-stop-shop resource page to help users understand what was changing and what steps they could take to adapt to the changes. By the time of the shutdown, over 80 individuals had spent time on that page. The resource included:

While this was largely just a matter of creating effective documentation, it also acted as a game plan. It gave users the tools they needed to adapt to a potentially overwhelming change.

Finally, I organized a group of subject matter experts who were trained to transition impacted users in their unique domains. This group was made up of administration, application, and analytics leaders across multiple teams and departments. Identifying and arranging the right people was crucial in addressing users’ real concerns once they were informed that they would be impacted.

Step 3: Personally Support Users

Having good resources isn’t enough if those resources aren’t reaching the people who need them. We wanted to actively guide people through this change, so we reached out to those who depended on the legacy database. We ended up connecting with over 250 users via email, direct message, or intake form.

Each message was tailored to who the person was (business-minded or technical-minded), what was going to change for them, and what they needed to do next. Some of the use cases we learned about in this process revealed how critical the database was:

If we had just counted dollar value or tracked recent usage, these important use cases would have been missed. Yet, if these pipelines were to turn off one day without proper change management, people all over the company would be severely impacted and wouldn’t know why.

Thanks to our team’s joint work with the client, we successfully retired both databases with minimal disruption—all within the constraints of the organization’s larger initiatives. This project wasn’t just a win because of the technical transformation, but also because of the organizational transformation. The project’s impact was and will continue to be massive:

At Elder Research, a MANTECH company, we believe caring for people is at the core of any successful transformation. Yes, you need the right data structures, but more importantly, you need empathy, intentionality, and transparency during change.

We could have just pulled the plug, but we chose not to. Instead, we partnered with the business, uncovered the risks, and brought everyone along.

If you’re an analytics leader who’s weighed down by legacy systems, know that retiring old tech isn’t just a migration; it’s a conversation.

Our team is always glad to chat about projects like this and others on your radar. We’d love to discuss ways we can help you see it solved.