How to Sunset a Legacy System Without Destroying Team Morale

[clears throat] Have you ever had to tell a team that the system they've maintained for years is being retired? That moment when you see their faces fall, knowing their expertise is about to become obsolete. The thing that nobody talks about, sunsetting a legacy system isn't a technical problem, it's a people problem with technical constraints. Today, I'm sharing a story from the Voyager program at NASA, where we migrated decades-old systems to AWS without losing a single team member or a single critical feature. So stick around.

[upbeat music] Welcome to Engineering Evolved, where business meets innovation and technology drives transformation. Each episode, your host, Tom Barber, explores the challenges and opportunities facing the organizations in the middle, the forgotten ground where startup rules no longer apply and enterprise playbooks are far too large. From scaling systems and leading teams to aligning engineering with business goals, this is where practical insight meets real-world experience. Engineering Evolved, guiding today's leaders through the evolution of engineering. Welcome to Engineering Evolved, the podcast for engineering leaders at medium-sized companies who are tired of being told, "Just go do what Google does.

" I'm your host, Tom Barber, and this is episode number 10. Every week, I share real stories and practical frameworks from the trenches of engineering leadership. No Silicon Valley fairytales, no enterprise bureaucracy, just battle-tested strategies for companies with fifty to a thousand engineers who need to move fast without breaking everything. Today, we're talking about something that keeps many of you up at night. How do you sunset a legacy system that's been the backbone of your operations for years without destroying the morale of the team that built it?

Because here's what I've learnt, the technology is the easy part. The hard part is helping people feel valued when their expertise is being phased out. So let's dig in. Before I jump into this case study, I want to ask you something. Think about your current environment for a second.

Do you have systems running that are older than some of your engineers? Maybe it's that monolithic application written in a language nobody wants to touch. Maybe it's hardware that needs special handling. Or maybe it's just tribal knowledge locked in the heads of three people who are all thinking about retirement. Now, here's the uncomfortable question.

What happens when you need to migrate away from that system? Not if, but when, because eventually you will. And when that time comes, you're going to face a choice. You can treat it like a purely technical project, requirements, architecture, timelines, done. Or you can treat it like what it actually is, a transition that affects people's identities, their expertise, and their sense of value to the organization.

I learnt this lesson at NASA, working on systems that have been running longer than I've been alive. And I'm going to be honest with you, we got some things wrong at first, but we also got a lot right, and that's what I want to share with you today. Because whether you're a director of engineering at a two hundred person company or a VP of tech at a growing SaaS business, you're gonna face this challenge, and how you handle it will define your culture for years to come. Let me paint the picture. We were working with systems connected to the Voyager program.

Yes, that Voyager, the spacecraft that has literally left our solar system. And these systems were running on Sun Microsystems hardware. For those of you who don't remember, Sun Service-- servers were legendary in the nineties and early 2000s. They were rock solid, and they were com-completely obsolete. The hardware was failing.

Parts were impossible to source. The operating system hadn't been updated in years, and we were running critical data processing and communication systems on infrastructure that could die at any moment. And so the decision was clear, migrate to AWS. A lot of our existing JPL workloads had already been migrated to AWS. It was modern infrastructure, scalable, supported, all of the buzzwords.

But here's what made this complicated. The team maintaining these systems, they were virtuosos. They knew every quirk, every workaround, every undocumented feature. They could diagnose problems by sound. They had accumulated deep specialized expertise over the years, sometimes decades.

And now we're essentially telling them, "Everything that you know is going away. " So if you think about that for a moment, how would you feel if someone walked into your office tomorrow and said, "The technology stack you've mastered, we're replacing it entirely starting next month"? Here's a question for you. Have you ever been on the receiving end of that conversation? And if so, you know exactly how it feels.

If not, just try and imagine it. Really sit with that for a second. This is where most legacy migrations go wrong. Leaders focus on the technical milestones. Database migration complete, check.

Application replatformed, check. But they forget they're asking people to unlearn their competitive advantage and start over. So let me tell you what we did wrong, and I say almost because we caught ourselves, but only just. Why hire when you can partner? Concept Cloud's leading engineers build your startup's prototype without the overhead.

Launch faster. conceptcloud. com. The initial plan was classic. Bring in AWS experts.

They'll design the new architecture. The legacy team will provide documentation and answer questions during the transition. Then once everything's migrated, we'll train the legacy team on AWS, which was a clear handoff, right? Well, that was wrong. Completely wrong.

And here's what that plan actually communicated to the team. Your knowledge is only valuable as a reference document. These new people are the real talent. You're being managed out gracefully. We realized during a planning meeting when one of the senior engineers, someone who'd been with us on the program for fifteen years, asked a simple question, which was, "What happens to us when this is done?

" And there was no obvious answer, and the, the silence in that room was deafening. That question changed everything because it made us confront the truth. We were so focused on the tran-- technology transition that we'd forgotten about the human transition. When you're planning a major technology change, do you have a clear answer to what happens to the people before you start? Or does that cat-question catch you off guard?

And here's something I want you to think about. These weren't just engineers. These people had kept critical systems running through hardware failures, budget cuts, and organizational changes. They'd solve problems that never made it into the documentation because they'd solved them at two AM when nobody was watching. And that's the kind of expertise you can't capture in a requirements document.

So we stopped, regrouped, and completely changed our approach. So let me walk you through what we did instead, and I'm gonna give you the framework we developed because you can adapt it for your own legacy migrations. The first principle is expertise transfer, not knowledge handoff. We made the legacy team the migration leads, not consultants, not advisors. The leads, they owned the migration of their systems.

But here's the key. We paired each legacy team member with an AWS specialist in a true partnership, not the legacy person teaching the AWS person how the old system works, both of them learning together. Legacy expertise meets modern capabilities. And this meant that the legacy team had to learn AWS. They had to learn containerization, infrastructure as code, managed services, and they went deep.

And the AWS specialists, they had to learn the domain, the edge cases, and the reasons why things were built the way they were. And we called these pairs transition pods. Each pod owned a system end to end. They mapped the legacy functionality, designed the new architecture together, and implemented migration. No hands-off, no throw it over the wall, complete ownership from start to finish.

The second principle was celebrate the old before embracing the new. And we did something that might sound counterintuitive. Before we migrated anything, we documented and celebrated what the sy- legacy systems did well. We held systems re-retrospectives, where the team walked through the architecture and explained the clever solutions they'd built. We made it clear we weren't killing these systems because they were bad.

We were evolving them because the context had changed. You know, if you think about it, these Sun servers had run for decades with minimal downtime. That's not a failure. That's really a massive success. The problem wasn't the system, it was that the infrastructure couldn't be maintained anymore.

By acknowledging this explicitly, we took away the shame because there shouldn't be shame in building something that eventually becomes legacy. Every system becomes legacy. That's not a bug. It's a feature of successful software that lives long enough to outli- outlast its original context. The third principle is create new expertise, don't just transfer old expertise.

And this is crucial, especially for medium-sized companies listening. You can't just migrate to new technology. You need to build new patterns that fit your organization. We didn't just copy the legacy system to AWS. We used the migration as an opportunity to rethink how we operated.

So the legacy team brought their understanding of reliability, operational patterns, and edge cases. The AWS specialist brought modern architectural patterns, and together they created something new. For example, the old systems had sophisticated monitoring built through years of operational experience, things that would page someone when specific log patterns appeared. When we migrated, we didn't just replicate those alerts. We rebuilt them using CloudWatch and Lambda, but informed by all that operational wisdom.

And the patterns were new. The knowledge was timeless. Fourth principle, which is measure success through people, not just systems. And so we tracked two sets of metrics. Yes, we tracked the technical migration, services moved, functionality verified, performance benchmarks, but we also tracked the human side.

We measured how many legacy team members are leading architectural decisions in the new system, how many are teaching others, how many feel confident in their new expertise. And six months after the migration, every single person from the legacy team had become a go-to expert on something in the new architecture. Not on how the old system worked, but on how the new system should work. And that's a win. Okay, so let's make this part tactical.

If you're facing a legacy migration, here's your playbook. Step one, start with future state convers-conversation. Before you talk about what's going away, talk about what's coming. Be clear and honest. Here's why we need to migrate.

Here's what the new system will enable, and here's why your expertise is critical to making this successful. Notice the framing. Your ex-expertise is critical, not your knowledge of the old system will help. Step number two is create the transition pods that I mentioned. Pair legacy experts with new technology specialists.

Give them real ownership, not the fake kind where they're consulted. Real ownership with decision-making authority. And here's something we learned. Make sure both people can say no. If the legacy sy- person-- If a legacy person says this migration approach will break functionality X, that has to be enough to stop and rethink.

Similarly If the new person says, "This architectural pattern won't scale," that also needs to be taken seriously because it's a partnership of equals. The same minds that worked on the last Mars rover now work on yours. Concepta Cloud builds startup MVPs that perform. Conceptacloud. com.

Step number three is document and celebrate. Before you change anything, capture why things are the way they are. Video walkthroughs, architecture decision records, lesson learned documents. Make it clear this isn't archeological documentation. This is capturing hard-won wisdom.

At NASA, we created what we called legacy lesson documents. Each one captured a specific decision or pattern that explained what problem was this solving, what alternatives were considered, what did we learn, and these became onboarding documents for new people joining the team. Step number four is build confidence through progressive ownership. Don't expect people to learn everything at once. Start small, bounded migrations where the legacy team can succeed.

Build confidence, celebrate wins, and then tackle bigger challenges. We started with a monitoring service which was low risk and well understood and clear success criteria. The team learned AWS, learned infrastructure as code, learned the new patterns, and when that worked, they had proof that they could do this. But also, step number five is create a safety net, and this is important. When people are learning new technology while keeping the old systems running, they need to know it's safe to not know things.

We instituted office hours where people could ask any question, no matter how basic. We normalized saying, "I don't know. Let me find out. " For medium-sized companies, you don't have unlimited resources. You can't hire a whole new team and run parallel systems forever.

You need your existing people to level up, and that only happens when it's psychologically safe to be a beginner again. So here's a question for you. Do your senior engineers feel safe saying, "I don't understand this new technology," in front of their peers and leadership? Because if not, you're gonna have a hard time with any technology transition. So what happened at NASA?

We completed the migration. All the critical functionality moved to AWS. Zero data loss, zero extended outages. But more importantly, the team evolved. People who'd spent twenty years as Sun server experts became AWS experts.

They wrote blog posts, presented at internal conferences, and they became mentors to engineer, engineers joining the team. And the thing that made me happiest, eighteen months after the migration when we had a critical issue with the new system, it was one of the original legacy team members who diagnosed it. Not because he knew how the old system worked, but because he understood the domain deeply and had learned the new technology thoroughly. And that's what success looks like. Think about what we could have lost if we'd done this wrong.

We could have lost institutional knowledge. We could have lost talented people. We could have created a culture where getting your system sunset means getting sidelined. And instead, we created a culture where evolution is expected and expertise is something you continuously build, not something you defensively pr- protect. And especially in the space industry where your spacecraft may last for twenty years, the systems that power that spacecraft are gonna change.

And so you have to ensure that the team feel empowered to change with them. So let me bring this home for you. If you're sitting on a legacy system that needs to be retired, you have a choice to make right now. You can treat it as a technical project and hope that the people part works out, or you can treat it as a transformation that happens to involve technology. Here's my challenge to you for next week.

If you have a legacy system that needs to be sunset or will be sunset in the next year, schedule a conversation with the team maintaining it. Not about the migration plan, about them. Ask them, like, "What do you want to learn? What are you worried about? And how can we make this transition something you own, not something that happens to you?

" Just have that conversation. You'll learn things that will make your migration better. And if you're struggling with how to, how to structure this kind of transition or you need help building the frameworks and communication plans that actually work, this is exactly what we do at Concepta Cloud. We've helped companies migrate critical systems while keeping their teams engaged and growing. Not by dropping in architects and consultants who take over, by partnering with your team to build their capabilities whilst achieving technical outcomes.

You can reach me through the show notes if you want to talk through your specific situation. Sometimes just talking through the people dynamics with someone who's been there makes all the difference. As always, I'd love to hear your stories. Have you been through a legacy migration? Are you facing a new one?

What's your biggest concern? The technical side or the people side? You can reach me on LinkedIn. Just search Tom Barber or through the Engineering Evolved website. I read every message, and your stories often inspire future episodes.

And if you found this episode valuable, share it with other engineering leaders who are dealing with legacy systems 'cause we're all in this together, figuring out how to evolve our organizations without leaving people behind. That's a wrap for episode ten. I will see you in a week's time for episode eleven. Until then, keep evolving. Bye for now.

Thanks for listening to Engineering Evolved with Tom Barber, where ideas meet innovation and leadership drives change. If you enjoyed today's episode, please leave a rating and review wherever you listen. It helps more leaders discover the show and keeps the evolution moving forward. From idea to investor demo in weeks, not months. Concepta Cloud, world-class engineers accelerating startup success.

Conceptacloud. com.