Old Growth, New Trails

The team was still introducing themselves when I walked into the first standup.

Names and faces, everyone figuring out who knew what. The migration had barely started: a few proof-of-concept services, some early architectural decisions, and a whiteboard full of question marks. What lay ahead: sixty years of mainframe, a million transactions per minute at peak, and no room for error.

This is a story about building foundations. No clever algorithm saved the day. The work was slower: creating structure that let an entire organization move forward together.

The System That Runs Travel

Sabre isn’t just another enterprise system. It’s the system (or one of a handful) that makes global travel reservations work. When you book a flight, there’s a decent chance the request passes through infrastructure that traces back to the 1960s.

The mainframe at the heart of this system wasn’t built for today’s scale, but it grew into it. Sixty years of continuous operation, continuous evolution, continuous pressure. Four hundred airlines. Eighty-eight thousand travel agents. A system where “move fast and break things” would mean stranded passengers in airports worldwide.

The decision had been made: migrate to a modern architecture. Not a big-bang rewrite as that would be suicide for a system this critical, but a gradual transition. Run old and new in parallel. Let the new system prove itself before taking over.

This is where I came in. A team just forming, with everything still to be built.

Taking the Lead

Within weeks, I was leading the team. Someone needed to make decisions and drive forward, and I was the one doing it.

The first work wasn’t glamorous: migration features, orchestration frameworks, resolution patterns. The plumbing that would let old and new systems communicate. Every transaction type needed to flow through both systems, results compared, discrepancies logged.

But more important than any single feature was the structure we put around the work. How should teams organize their code? What patterns should they follow? Where do orchestration rules live? How do you test against a sixty-year-old mainframe?

These questions needed answers that would scale beyond our team.

The Golden Path

As more teams joined the migration, the challenge shifted. It wasn’t enough to build good software. We needed to build a path that other teams could follow.

We called it the golden path: a clear structure for how new teams should approach their piece of the migration. Directory layouts, naming conventions, testing strategies, deployment patterns. Guardrails that prevented the chaos of fifty teams each inventing their own approach.

The goal was simple: when a new team joined, they shouldn’t spend their first month figuring out how to structure their work. They should be able to look at what existed, understand the pattern, and start contributing.

It mattered because we knew the endgame. The migration was too big for the core team. Eventually, contractors would need to pick up features and run with them. The golden path wasn’t just about our productivity. It was about enabling an organization to scale.

For team augmentation to help on terrain like this, incoming engineers need a trail they can follow: working examples, clear conventions, and people to pair with. Extra hands alone don’t supply that structure.

The Serialization Problem

Sabre had existing serialization frameworks, code that transformed modern data formats into the binary protocols the mainframe expected. The problem was that these frameworks were both slow and hard to debug.

Performance was an issue. Every request to the mainframe had to be serialized and deserialized. At a million transactions per minute, milliseconds matter.

But the bigger problem was comprehension. When something went wrong, engineers spent hours tracing through the serialization code trying to understand what happened. The existing frameworks were powerful but opaque. You could use them, but good luck understanding why a particular byte ended up where it did.

We built a replacement: a declarative approach where teams could describe their binary formats in a schema, and the framework would generate serialization code that was both performant and debuggable.

When something went wrong, you could look at the schema, understand the expected format, and quickly identify where reality diverged from expectation. The framework didn’t just translate data; it made the translation visible.

Becoming the Spearhead

Over time, our team became the model for the organization. We’d established patterns that worked, and others noticed.

Other teams would look at our code for reference. They’d ask how we structured certain problems. The golden path we’d created wasn’t just documentation. It was living in our codebase, demonstrating how things should be done.

It required discipline. Every PR had to be exemplary. Every pattern had to be intentional. We were building examples that dozens of engineers would follow.

The investment in quality paid off in an unexpected way: it enabled scale through contractors. When the organization brought in external developers to accelerate the migration, they could look at our code, understand the patterns, and contribute meaningfully. The training burden was minimal because the codebase taught them what they needed to know.

The Synchronization Layer

The synchronization service was what made the whole approach possible.

Without it, migration would have meant a big bang: flip a switch, hope everything works, deal with the consequences. With synchronization, old and new systems could run simultaneously. Every transaction processed by both, results compared, discrepancies caught before they affected customers.

That safety net let the organization move incrementally. Migrate one feature, validate it, gain confidence, move to the next. No all-or-nothing moments. No praying that the new system worked because there was no going back.

The synchronization layer was technically complex: managing state between two very different systems, handling race conditions, dealing with the inevitable discrepancies. But the complexity was worth it. It transformed a terrifying cliff into a gradual slope.

That coexistence is a central concern in legacy modernization: how to prove the replacement’s behavior while the existing system still carries the business, not just how to build the replacement.

The Resolution

I spent about two years on this engagement. When I moved on, the migration was ongoing. You don’t retire a sixty-year-old mainframe quickly. But the foundations were solid.

The golden path was established. New teams knew how to contribute. The serialization framework was in production, making transformations fast and debuggable. Contractors were picking up features and delivering quality work. The synchronization layer was running, letting old and new coexist safely.

The work would continue without me. That was the point.

The Lesson

The technical artifacts (frameworks, patterns, code) were just the visible part. The real work was building foundations that let an organization scale beyond any individual team.

When you’re facing a migration this large, heroics don’t scale. What scales is structure: clear patterns that new teams can follow, quality standards that let contractors contribute, and safety nets that allow incremental progress.

Building those foundations takes longer than solving any single problem. But it’s the difference between a migration that depends on specific people and one that can absorb dozens of engineers and keep moving forward.

The mainframe will eventually be retired. When it is, it won’t be because one team wrote brilliant code. It’ll be because the organization built infrastructure for working together.

Key Takeaways

The business context: A 60-year-old mainframe processing up to 1 million transactions per minute for 400 airlines and 88,000 travel agents. Critical infrastructure that can’t fail, can’t stop, and can’t be replaced overnight.

The approach: Join a forming team, take leadership, build foundations. Create golden paths so incoming teams know how to contribute. Establish quality standards that enable scaling through contractors.

The serialization challenge: Sabre’s existing frameworks were both slow and hard to debug. Built a replacement that was faster and made transformations visible, crucial when debugging issues at scale.

The synchronization strategy: Running old and new systems simultaneously, comparing results, building confidence incrementally. No big bang, no all-or-nothing moments.

Why this matters for engineering leaders: Legacy migrations aren’t just technical problems. They’re organizational scaling problems. The question isn’t whether your team can build good software. The question is whether you can build foundations that let dozens of teams contribute without blocking each other.

Facing a legacy system migration? The Pointer Assessment maps migration risks and priorities. The Chase is hands-on execution alongside your engineers, building and validating the foundations. The Unleashing is the ownership-transfer phase: pairing, documentation, and independent practice so your team can carry the work forward. Let’s talk about your architecture.