- SQL Server 2016 leaves extended support on July 14, 2026. Windows Server 2016 follows on January 12, 2027. If your legacy estate sits on either, the do-nothing option now has a price tag.
- AI changed the economics of exactly one of the five modernization strategies: rebuild. It did not change the other four, and it did not change where projects actually fail.
- The cheapest insurance in any modernization is 30 days of usage logs. Systems are migrated as documented and used as logged. The gap between the two is where budgets die.
- Acceptance criteria written as executable tests, signed before any code, are the difference between a cutover and a hostage negotiation.
We have shipped more than 200 production systems since 2014, for clients including Bayer, Takeda, Adidas, and Rockwell Automation. A large share of that work started the same way: a system everyone depends on, that nobody fully understands, that just became someone's urgent problem. This guide is the advice I give before any contract is signed. It is short because most of what is written about modernization is padding.
The deadlines that are real this year
Modernization projects usually start for a boring reason: a support clock runs out. Two clocks matter right now. SQL Server 2016 leaves extended support on July 14, 2026. Windows Server 2016 follows on January 12, 2027. After those dates Microsoft stops shipping security patches unless you buy Extended Security Updates.
Be honest about what ESU is. It covers critical security fixes only. The price climbs each year, and it changes nothing about the system's actual condition. ESU is a fine bridge if it leads to a dated plan. It is a slow leak if it leads to next year's renewal.
If neither clock applies to you, the calculus is calmer than vendors suggest. A stable system on a supported platform is not a crisis. It is an option you hold. The rest of this guide is about exercising that option deliberately instead of under duress.
The 5R menu, with the parts vendors skip
The standard framework lists five strategies. It is a useful menu and a terrible decision tool, because every consultancy quietly steers you toward the strategy it staffs best. Here is each option with its honest catch, plus the sixth option assessments always omit.
Rehost
Move the application to new infrastructure without touching the code.Right when: An OS or database deadline is the real driver, the application is stable, and nobody is asking for new features.
The catch: You keep every defect and every licence. Cloud bills often come in higher than the hardware you owned, because the app was sized for that hardware. Treat rehosting as buying time with a date attached, not as modernization.
Refactor
Restructure the code while keeping the behavior identical.Right when: The team still understands the codebase, the platform underneath is healthy, and change requests are what hurt.
The catch: Refactoring is invisible to the business, so its funding dies first in any budget review. Pair it with a feature people are waiting for, or expect it to be cancelled mid-flight.
Rearchitect
Change the structure of the system to remove a scale or integration limit.Right when: The system earns its keep but its shape blocks you. A monolith that cannot expose the API your partners need is the classic case.
The catch: This is the riskiest middle path. You pay rebuild-level attention for less than rebuild payoff. Only take it when the architectural limit is measured, not suspected.
Rebuild
Rewrite the system, or part of it, on a modern stack.Right when: The functionality matters, the technology is dead, and the people who could maintain it are gone or going.
The catch: The failure mode is scope. Rebuild what the logs say people use, not what the old system contains. This is also the one strategy whose economics AI has genuinely moved, which the next section covers.
Replace
Retire the custom system and adopt a commercial product.Right when: The workflow is commodity. Payroll, ticketing, expense claims, standard CRM.
The catch: The data and habit migration costs more than the licence. And if the workflow actually differentiates you, you will spend years customizing the product back into a new legacy system.
Retire
Turn it off.Right when: Usage logs show screens and reports with no users. Every estate we have looked at has them.
The catch: Nobody bills consulting hours for this option, so assessments skip it. Archive the data and post a shutdown date. Then watch how few people notice.
What AI actually changed, and what it did not
Three things genuinely changed. First, code archaeology got cheap. A model can read a codebase nobody understands and produce a usable map: a module inventory, the data flows between modules, candidate business rules, and a list of code that nothing calls. That used to be weeks of analyst time. It is now hours, with review.
Second, characterization tests got cheap. Writing tests that pin down what a system currently does, bug for bug, was always the most tedious work in software, which is why it was always skipped. Models are good at tedious. There is no longer an excuse for cutting over without a behavioral safety net.
Third, rebuild economics shifted. A workflow that took a team a quarter to rebuild can often be rebuilt and tested in weeks. Systems that sat in the refactor column because a rewrite felt unaffordable now belong in the rebuild column. This is the single biggest strategic change since the 5R framework was written.
Now the limits. The most dangerous business rules live nowhere a model can read: in an operator's head, in twenty years of manual data corrections, in a spreadsheet on someone's desktop, in the muscle memory of a month-end routine. No tool finds what was never written down. Only interviews and data archaeology do.
And plausible is not correct. A model will explain a COBOL paragraph or a 4,000-line stored procedure fluently and sometimes wrongly. Every AI-generated claim about system behavior gets verified against captured production data, never against the model's confidence. We treat AI output as a fast first draft of the truth, and we treat the old system itself as the only authority on what the truth is.
How we actually run one
- Inventory observed behavior, not documentation. Pull application logs, database query statistics, scheduled-job history, and API traffic for 30 days. The documentation describes the system as designed. The logs describe the system as used. In my experience the two have never matched, and the logs are the ones that are true.
- Rank workflows by who screams. A small set of workflows carries the operational load. Find them by consequence: which jobs page someone at 2 a.m. when they fail, which screens have daily users, which reports the CFO opens, which outputs land in front of a customer or a regulator. That ranking is your migration order.
- Write acceptance criteria before any code. For each workflow: given these real inputs, the new system must produce these outputs, within this tolerance, at this volume. If you cannot write that sentence yet, you do not understand the workflow, and neither does any vendor quoting you a fixed price for it.
- Use the old system as the test oracle. Capture production inputs and outputs for a representative period, including month-end if you have one. That corpus is your regression suite. It is worth more than every specification document in the building.
- Strangle, do not switch. Route one workflow to the new system while the old one keeps running. Reconcile outputs daily. Widen the routing only when the deltas reach zero, or when the remaining deltas are explained and accepted in writing by the workflow owner.
- Decommission with a date. A system that is "mostly migrated" costs the same to run as one that was never migrated. The project is not done when the new system works. It is done when the old one is off and its licences are cancelled.
The checklist before you sign anything
Run this before engaging any vendor, including us. Every unchecked item is a change order waiting to happen, because the vendor will discover it on your budget instead of theirs.
- 30 days of usage logs pulled and ranked: screens, jobs, reports, API calls.
- Each workflow mapped to a named owner who will sign its acceptance criteria.
- Data quality sampled: 100 real records traced end to end, defects counted.
- Every inbound and outbound interface listed, with the team on the other side contacted.
- The undocumented-rules interview done with the longest-tenured operator you have.
- Acceptance criteria drafted as executable tests, not prose.
- A parallel-run window agreed with the business, including one period close.
- A rollback path defined for every cutover step.
- A decommission date in the plan, with a name attached to it.
- The do-nothing baseline priced: extended security updates, old licences, the next outage.
Where the bodies are buried
Four failure modes account for most of the wreckage I have seen. Data quality is first: migration exposes every shortcut taken in the last two decades, and fixing data is business work, not vendor work, so it never appears in the quote. Second is the interface nobody owns, the nightly file a partner has consumed since 2009, discovered the week before cutover. Third is the retirement of the one person who knows why the system rounds the way it does. Interview that person now, not during the project. Fourth is the big-bang rewrite, which fails for a structural reason: it asks you to reproduce twenty years of accumulated behavior in one release, with one chance to be right.
Every one of these has the same antidote: smaller pieces and real production data, under a contract that pays on demonstrated behavior instead of effort.
How we would start with you
We do not sell modernization assessments. We sell the first proof. You pick one workflow from your legacy system, the one the logs say matters. We scope it with you and write acceptance criteria you sign. Then we build the modern version in your environment in two weeks. The price is $10,000, paid only after every criterion passes. Nothing upfront.
If the system deserves a larger program, it runs the same way: two-week sprints, each with its own signed criteria, each ending in something running in production or a clear reason it is not. Everything we build is built to SOC 2, HIPAA, and GDPR standards, with EU AI Act-aligned delivery. The strangler pattern is not just an architecture. It is how we prefer to be paid.