Keep, Move, Replace, or Rebuild? A Legacy System Modernization Decision Guide for Mid-Market Owners and Operators
The takeaway: Don’t start a modernization by picking new technology. Start by scoring every aging system on business value and risk, give each one of five moves (retire, keep with guardrails, move, replace, or rebuild in slices), and write a plan that names milestones, the work, and the date the old system turns off. When the U.S. Government Accountability Office (GAO) checked plans for the 11 federal legacy systems most in need of modernization, only three had all three of those elements (GAO-25-107795, July 17, 2025).
Every mid-market company has one: the order system built in 2009, the server nobody wants to reboot. Here’s how to decide its fate without a big-bang rewrite.
Why “we’ll replace it next year” gets expensive
Old systems charge interest. In a July 2020 McKinsey survey of 50 CIOs at financial-services and technology companies with more than $1 billion in revenue, CIOs said 10–20% of the budget meant for new products gets diverted to tech-debt problems, and estimated tech debt at 20–40% of the value of their whole technology estate (McKinsey, Oct 6, 2020). McKinsey’s 2023 follow-up repeats those 2020 figures rather than reporting a new survey (McKinsey, Apr 25, 2023). A larger 2023 survey by consulting firm Protiviti (1,050 technology executives) found organizations spend an average of 30% of IT budgets managing technical debt (Protiviti, 2023). Both samples lean toward big companies, so treat the numbers as directional.
GAO adds the risk side. Of those 11 critical federal systems, eight use outdated programming languages, four have unsupported hardware or software, and seven run with known cybersecurity vulnerabilities.
Step 1: Score every system before you debate any of them
GAO built its list by asking 24 agencies for their three systems most in need of modernization (69 in total) and scoring them on 16 attributes, including age, vendor support, legacy languages, cybersecurity risk, and operating cost. A lighter version fits in one spreadsheet. Rate each system 1–5 on:
- Business value: What revenue or operations depend on it, and how often do people work around it?
- Vendor support: Is it still getting security updates, and when does support end?
- Skills risk: How many people can safely change it? If the answer is one person’s first name, that’s a 1.
- Security exposure: Known flaws you can’t fix, and whether it faces the internet.
- Cost to run: Licenses, hosting, and the staff time nobody tracks.
- Data access: Can you get clean data out for reporting or AI projects? McKinsey lists disjointed data architectures as a blocker to advanced analytics.
High value plus high risk goes to the top. Low value plus high risk is often the easiest win: turn it off.
Step 2: Pick one of five moves
Cloud providers have their own vocabulary for this. AWS’s migration guidance lists seven “Rs”: retire, retain, rehost, relocate, repurchase, replatform, and refactor (AWS Prescriptive Guidance). For owners and operators, five plain moves cover it:
- Retire. Shut it down and archive the data.
- Keep, with guardrails. Fine for stable, low-risk systems, or while you wait on something else; AWS names waiting for a vendor’s SaaS version as a common reason. Guardrails mean supported software, backups you’ve test-restored, and no direct internet exposure.
- Move it. Shift it to better infrastructure with little or no code change. For large migrations, AWS recommends moving first and modernizing afterward, because changing the app mid-move is the most complex path.
- Replace it. Swap in a SaaS or packaged product when the system does commodity work like payroll or ticketing. Budget for data migration and process change, not just licenses.
- Rebuild in slices. For the system that’s truly your edge, rebuild a piece at a time.
Why “in slices” matters
Software author Martin Fowler writes that the plan to “just build a new system that does exactly the same” usually fails: “we’ve seen this simple-sounding plan go down in flames most of the time” (Martin Fowler, “Strangler Fig,” Aug 22, 2024). His alternative, the Strangler Fig approach, builds new pieces alongside the old system and moves behavior over gradually. You’ll build some temporary bridge code so old and new can run together; Fowler argues the lower risk and earlier payoff outweigh that cost. McKinsey’s advice lands in the same place: skip infrequent megaprojects and set aside a steady slice of budget for paying down debt.
Step 3: Let triggers set the timeline
Some events should move a system up the list regardless of score:
- End of vendor support. Federal policy in OMB Circular A-130, quoted in CISA’s BOD 26-02 (Feb 5, 2026), says unsupported systems should be “phased out as rapidly as possible.” That directive binds federal agencies, not private companies, but the logic carries, especially for internet-facing gear like firewalls and routers, which the directive names.
- Shrinking skills. GAO flags Treasury systems written in COBOL and Assembly, languages with a dwindling pool of people who can support them.
- Flaws you can’t patch. GAO cites an EPA system whose known vulnerabilities can’t be fixed without modernization.
- A contract renewal. It’s the cheapest moment to change course.
Step 4: Write a one-page plan with three parts
GAO’s minimum for a documented modernization plan is milestones, a description of the work, and the planned disposition of the legacy system. Two of the 11 federal systems had no plan at all. For each system, write the move, the first slice, the date the old system goes dark, and who owns the data afterward. If you can’t name a turn-off date, you’re not modernizing. You’re running two systems.
Where outside help fits
Modernization decisions sit between finance, operations, and IT, so they stall. A fractional CTO can run the scoring, pressure-test vendor quotes, and sequence the slices so the business keeps moving. Yellow Coop does this through what we do, at the engagement levels on how we engage. If one system is keeping you up at night, start with a 20-minute call.
Internal links: Operate, What We Do, How We Engage, Track Record, Contact, Insights.
Sources
- Information Technology: Agencies Need to Plan for Modernizing Critical Decades-Old Legacy Systems (GAO-25-107795) — U.S. GAO, Jul 17, 2025
- Tech debt: Reclaiming tech equity — McKinsey & Company, Oct 6, 2020 (survey of 50 CIOs, July 2020)
- Breaking technical debt’s vicious cycle to modernize your business — McKinsey & Company, Apr 25, 2023
- Global Technology Executive Survey: The Innovation vs. Technical Debt Tug of War — Protiviti, 2023 (n = 1,050)
- Migration strategies — AWS Prescriptive Guidance (accessed Oct 16, 2026)
- Strangler Fig — Martin Fowler, Aug 22, 2024
- BOD 26-02: Mitigating Risk From End-of-Support Edge Devices — CISA, Feb 5, 2026
- What we do and How we engage — Yellow Coop
Found this useful? Share on X