Legacy enterprise replacement in 3 months: the compromises that work

“We have an old system, but a migration is unrealistic and a big-bang cutover can't work.” We hear it a lot. The fear is healthy — of a rewrite that turns into an 18-month project with no working output. For JUST the problem was inverted: the legacy system was failing, and we had 3 months for the full replacement, because its licence was expiring.

We made it. Here's how — and what we consciously left out of the first version to make it possible.

Rule 1: Scope triage before kickoff

JUST's legacy system covered ~120 business use cases. A full replication would take 9-12 months. Three months only works if scope is cut to must-have at Day 1 production.

Triage happened with the CFO and IT manager in a room, placing each feature into one of four buckets:

• Day 1 MUST (40%): business stops without it. Commissions, seller orders, core CRM.
• Day 30 OK (25%): missing, but the admin can do it manually for 30 days. Reporting dashboards, some admin UI, historical comparisons.
• Day 90 OK (20%): no one would notice for 3 months. Bulk export, some third-party integrations.
• Day 360 MAYBE (15%): no one actually uses it. Legacy features nobody had requested for years.

Outcome: we delivered 40% at Day 1, 65% within a month, 85% within a quarter. 15% never shipped — nobody asked for it.

Rule 2: Core data model first, UI last

On a 3-month rewrite it's tempting to start with the frontend — that's what the client sees. But if you have to change the data model later, you rewrite the frontend too. Lost time.

For JUST:

• Week 1-2: data model (SQL schema) + legacy data migration
• Week 3-5: business logic (commissions, orders, shared workflows) as pure functions + unit tests
• Week 6-8: API on top of the business logic
• Week 9-11: UI (React admin + seller portal)
• Week 12: UAT, dual run, cutover

Frontend last means the core logic is done and tested before anyone writes the first button. If UAT surfaces something wrong in the business logic, the fix is one-shot — no cascading through the UI.

Rule 3: Parallel run for at least 2 weeks

Before the DNS switch / user cutover both systems have to run side by side and accept the same transactions. Specifics:

• The new system gets a copy of every transaction from the legacy system (read replica or event sourcing)
• Users keep working in the legacy
• Nightly comparison — do both systems show consistent states?
• Delta > 0.1% = alert, cutover postponed

In JUST's parallel run we found 4 cases where the systems differed. 3 were our bugs, 1 was a legacy bug the business had never spotted. Cutover happened when deltas were under 0.05%.

Rule 4: Cutover day — rollback is optional but addressed

Cutover day for JUST:

• Friday 22:00 — legacy freeze, read-only mode
• 22:15 — final data delta from legacy to new
• 22:30 — DNS switch + users redirected to new system
• 22:45 — smoke tests (login, create order, view commissions)
• 23:00 — “go live” signal or rollback trigger

Rollback trigger: if smoke tests fail by 22:55, DNS flips back to legacy, migration is reset. Legacy runs read-only through the weekend, retry cutover on Monday. On a 3-month project with a hard deadline a rollback plan has to exist — but we never needed it. Good preparation eliminates it.

Rule 5: Week 1 post-launch = bug-fixing sprint

Production differs from staging. Even after thorough UAT, bugs surface — edge cases no one tested. Week 1 is reserved for 100% of team capacity on bug fixes. No development, no new features, only hot-fixes.

In practice: 10-20 bugs in week 1, 3-5 in week 2, 1-2 in week 3. From week 4 you're back on the roadmap. Anyone who schedules new features for week 1 creates chaos.

What we didn't ship and never shipped

From the 15% “Day 360 MAYBE” bucket:

• A custom report for an old quarterly structure changed in 2019 (nobody mentioned it; the business doesn't need it)
• An integration with an ERP the client replaced during the project
• 3 specific bonuses for the top 5 sellers, replaceable by a manual process

The legacy system had accumulated 15 years of features that someone once needed and later didn't. A rewrite is a chance to simplify. Not repeating that cycle = only building features the business explicitly requests.

The takeaway

A 3-month legacy replacement is possible when:

• Scope triage with business is at the start, not mid-project
• Data model → business logic → API → UI, not the reverse
• Parallel run > 2 weeks with no deltas
• Cutover day has a rollback plan, even if unused
• Week 1 post-launch = bug-fixing sprint, not roadmap

More clients fit this model than the market says. The fear of rewrites usually comes from a different story — the 12-month project that failed because of missing triage. Triage it properly and 3 months is enough.