Tom Barber (00:02)
Ahem.
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.
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 fairy tales, no enterprise bureaucracy, just battle tested strategies for companies with 50 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 learned. 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 learned this lesson at NASA, working on systems that have been running longer than I've been alive.
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 200 person company or a VP of tech growing SaaS business, you're going to face this challenge and how you handle it will define your culture for years to come.
Ahem.
Let me paint the picture. We were working with systems connected to the Voyager program. Yes, that Voyager, the spacecraft has literally left our solar system. And these systems were running on Sun Microsystems hardware. For those of you who don't remember, Sun servers were legendary in the 90s and early 2000s. They were rock solid and they were 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 work around, 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. And 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.
The initial plan was classic, bring in AWS experts, they'll design a new architecture, the legacy team will provide documentation and the 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 and you're being managed out gracefully.
We realized during a planning meeting when one of the senior engineers, someone had been with us on the program for 15 years, asked a simple question, which is what happens to us when this is done? And there was no obvious answer and the silence in that room was deafening. That question changed everything because it made us confront the truth. We were so focused on the 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 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 it's ultimate 2 a.m. 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 own the migration of our 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 call 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 over the wall, complete ownership from start to finish. The second principle was celebrate the old before embracing the new. When we did something that might sound counterintuitive, before we migrated anything, we documented and celebrated what the legacy systems did well. We held systems 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. 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 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 use 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 have 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 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 expertise is critical, not your knowledge of the old system will help.
Step number two is create the transition pods 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 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.
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 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 state of 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 normalize 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 going to 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 20 years as some server experts became AWS experts. They wrote blog posts, presented at internal conferences, and they became mentors to new engineers joining the team.
And the thing that made me happiest, 18 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 protect. And especially in the space industry where your spacecraft may last for 20 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.
And 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.
And if you're struggling with 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 Concept 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. Because we're all in this together, figuring out how to evolve our organizations without leaving people behind.
That's a wrap for episode 10. I will see you in a week's time for episode 11. Until then, keep evolving. Bye for now.