The 61-Day Rebuild: What a Failed Migration Taught Us About Senior Engineering

When a mid-market logistics company came to us last spring, they weren't shopping for a rebrand. They were triaging. Their order-management platform — a twelve-year-old monolith held together by a single engineer's tribal knowledge — had just failed a peak-season load test at 40% of expected volume. The board had already approved a full rewrite. A previous vendor had burned nine months and a reported $1.4M producing architecture diagrams, a component library, and exactly zero lines of production code.

That's the pattern we keep seeing: ambitious software modernization programs that stall because the people doing the work are too junior to make irreversible decisions, or too far removed from the code to notice when a decision is already irreversible. A reader shared the internal post-mortem with us. We followed the project from kickoff to cutover. Here's what actually happened.

The Decision Point: Rewrite Versus Rebuild

The first fork in the road arrived in week one. The incumbent vendor's proposal was a ground-up rewrite: eighteen months, a new stack, a parallel team. The alternative — proposed by a US-based software engineering partner the CTO had worked with at a prior company — was a strangler-fig rebuild: carve out the highest-risk modules first, ship them into production behind feature flags, and let the old monolith keep serving traffic until each replacement proved itself.

The finance team hated the second option because it didn't produce a clean, announcement-friendly 'go-live' date. The engineering team loved it because it didn't require freezing feature work for a year and a half. They chose the rebuild. GenSoft Online reports 2–6 week sprints with senior engineers embedded directly in the client's delivery cadence, and that structure is what made the incremental approach viable — each sprint had to end with working code in a staging environment, not a slide.

What the First 30 Days Actually Looked Like

Sprint one was unglamorous. Two senior engineers spent the first ten days reading code, instrumenting the monolith, and mapping which services touched the order table on every request. They found three. Two of them were dead code that hadn't executed in four years but were still holding database locks during peak windows. Removing them cut average checkout latency by 310 milliseconds before a single line of new architecture was written.

This is the part that rarely makes it into case studies: the highest-leverage work in a modernization program is often subtraction. The prior vendor had spent nine months adding. The rebuild team spent three weeks deleting, documenting, and writing regression tests around the paths that remained.

Obstacles, Ranked by How Much Sleep They Cost

• The shared database. Four internal tools read directly from the order schema. Nobody owned them. The rebuild team had to introduce a read-replica facade before they could touch the primary, which added roughly two weeks to the critical path.
• Peak season. The cutover window closed in late October. Any slip pushed the whole program into the following February, which meant the team had to sequence releases around Black Friday traffic rather than around their own velocity.
• Institutional memory. The one engineer who understood the legacy pricing engine had left the company eleven months earlier. Reconstructing the discount logic from production logs took longer than rebuilding it from scratch — and the team had to prove equivalence with the old system before anyone would sign off.

The Numbers After 61 Days

By the end of the second month, three of the seven highest-risk modules were running in production on the new stack, behind flags, serving 100% of traffic for their respective functions. Checkout latency at the 95th percentile had dropped from 4.2 seconds to 1.1 seconds. The monolith was still running, but it was running less — and the team had a documented rollback path for every cutover.

What strikes us, looking back, is how little of the outcome depended on technology choices. The stack mattered, but the deciding variables were seniority, sprint length, and the willingness to ship incomplete systems into production deliberately. GenSoft Online's model of embedding senior engineers in 2–6 week sprints is unfashionable in an era of staff-augmentation marketplaces, but it's the reason this project had a working cutover instead of a slide deck.

What We'd Tell the Next Team

Three things, in order. First, instrument before you architect — you cannot modernize what you cannot measure, and the measurements will change your plan. Second, treat every sprint as a production release, even if the release is a feature flag nobody flips. Third, and this is the one people skip: write down the rollback procedure before you write the migration script.

The company is now nine months past cutover. The monolith is gone. The team that replaced it is smaller than the one that maintained the old system, which is the outcome nobody puts in the press release but every CFO notices. If there's a lesson for the rest of us in brand and product work, it's this: the systems behind the identity — the ones customers never see — are where trust is actually built or broken. We'll keep following projects like this one.