1. Why modernization keeps getting postponed
Modernization is easy to postpone because the old system still works today. The costs of waiting are spread out and hard to see: slower releases, harder hiring, security patches that no longer exist, and workarounds that pile up.
| What you see | What it usually means |
|---|---|
| Small changes take weeks | Code is tightly coupled; every change risks breaking something else |
| Fixes “disappear” after a deploy | No reliable build and release process; changes made on the server, not in code |
| Only one person understands the system | High key-person risk; knowledge is not written down |
| Security scans flag the platform itself | The platform or language version is past end of life |
| Hosting or licence costs keep rising | Old versions need special hosting or paid extended support |
| Integrations break when a partner updates | Old libraries cannot speak current protocols or APIs |
None of these alone forces a rebuild. Together they show where to look first.
2. Keep, refactor, replatform or rebuild
There are four realistic options for each system. Most organizations end up using more than one.
| Option | What it means | Good when | Watch out for |
|---|---|---|---|
| Keep and patch | Stay on the current system; apply updates; reduce risk around it | The platform is still supported and the system meets business needs | It postpones, not removes, the decision |
| Refactor | Improve the existing code and upgrade versions in place | The core logic is sound and the platform has a supported upgrade path | Large version jumps can be as much work as a rebuild |
| Replatform | Move the same functions to a new platform or CMS, keeping content and data | The platform is the problem, not the business logic | Data and content migration is most of the work |
| Rebuild | Design and build the system again | Requirements have changed a lot, or the code cannot be safely changed | Highest cost and risk; needs strong scope control |
3. The six-question test
Answer these six questions for each system. Score each answer 0 (no concern), 1 (some concern) or 2 (serious concern).
| # | Question | 0 | 1 | 2 |
|---|---|---|---|---|
| 1 | Support: Is the platform, language and framework still receiving security updates? | Yes, for 2+ years | Ends within 12 months | Already ended |
| 2 | Change speed: Can a small change be built, tested and released in days? | Days | Weeks | Months, or nobody dares |
| 3 | Fit: Does the system still match how the business works? | Close fit | Some workarounds | Major workarounds or missing features |
| 4 | Code health: Can the team safely change the code? (tests, documentation, clear structure) | Yes | Partly | No |
| 5 | People: Can you hire or keep people who know this technology? | Easily | With effort | Hard or impossible |
| 6 | Data: Is the data clean, documented and easy to move? | Yes | Mostly | No |
How to read the score
| Total | Usual answer |
|---|---|
| 0 to 3 | Keep and patch. Revisit in 12 months. |
| 4 to 6 | Refactor, especially if questions 1 and 4 score low. |
| 7 to 9 | Replatform, especially if question 1 scores 2 but question 3 scores low. |
| 10 to 12 | Rebuild, especially if question 3 scores 2. |
The score is a starting point for discussion, not a formula. A system that scores 2 on question 1 alone (unsupported platform) needs action soon, whatever its total.
4. The hidden cost of staying
“Do nothing” is a choice with costs. Price it honestly before comparing options.
- Security exposure. Unsupported platforms receive no fixes. New vulnerabilities stay open, and payment, privacy and accessibility rules often require supported software. For example, PCI DSS requires that known vulnerabilities be fixed through supported updates.
- Paid extended support. Some vendors and third parties sell extended support for old versions. It buys time, not a future, and the cost usually rises each year.
- Slower change. If every change takes weeks instead of days, the cost shows up as missed opportunities and staff time.
- Workarounds. Manual steps, spreadsheets and copy-paste work that people do because the system cannot.
- Key-person risk. If one person leaves, how long would it take someone new to make a safe change?
- Drupal 10 needs a plan now. Drupal 10 reaches end of life on December 9, 2026, so Drupal 10 sites need a supported upgrade path to keep receiving security fixes. The right path depends on each site’s modules and custom code. Drupal 8 and 9 sites face a larger jump and should be assessed with the six-question test.
- Hosting. Old versions may need special or isolated hosting, and they block upgrades of everything around them. On a shared server, one old PHP version can hold back the whole server.
5. How to modernize without a big-bang cutover
The goal is that customers, donors and staff barely notice the switch, except that things work better. No method can promise zero downtime in every case, but these patterns keep disruption small and reversible.
1. Strangler pattern (replace in slices). Put the new system beside the old one and move one section at a time: first the blog, then the product pages, then checkout. A routing layer (for example Cloudflare or the web server) sends each address to whichever system owns it. If a slice has problems, route it back.
2. Content and data migration in rehearsals. Write the migration as a repeatable script, not a one-time manual job. Run it many times on copies of real data, compare counts and samples, and fix problems before switchover day.
3. Redirect map. List every old address and where it now lives. Missing redirects lose search rankings and break links in old emails and ads. Test the full list automatically.
4. Parallel run. For business logic such as pricing, orders or calculations, run the old and new systems side by side on the same inputs and compare outputs before switching.
5. Feature flags and dark launch. Release new code switched off, then turn it on for staff, then a small share of visitors, then everyone.
6. Freeze, switch, verify. Agree a short content freeze, run the final migration, switch DNS or routing in a quiet period, then run a prepared checklist: forms, payments, logins, emails, analytics, redirects.
7. Rollback that is actually ready. Keep the old system running and untouched for an agreed period. Rolling back should be one routing or DNS change, tested in advance, not a plan written on the day.
6. A cost model you can fill in
We do not publish average project costs, because they vary too much with scope and data. Instead, compare options over the same period (we suggest 3 years) using your own numbers.
| Cost line (3 years) | Keep and patch | Refactor | Replatform | Rebuild |
|---|---|---|---|---|
| One-time project cost | ||||
| Data and content migration | ||||
| Hosting and licences | ||||
| Extended support or security patches for old versions | ||||
| Staff time on workarounds and manual steps | ||||
| Cost of slow change (estimated lost or delayed work) | ||||
| Risk allowance (security incident, outage) | ||||
| Total |
How to use it
- Fill in the “keep and patch” column first. It is usually higher than people expect.
- Use ranges, not single numbers, where you are unsure.
- Add a risk allowance for systems that score 2 on support (question 1).
- Ask vendors to fill in their columns using the same lines, so quotes can be compared fairly.
7. AI-assisted modernization in 2026
The biggest change since most modernization plans were written is AI coding assistants. In 2026 they can help read an old codebase, document it, translate modules to a new language or framework, and write tests, with engineers reviewing every step.
What it changes
- Discovery is faster. AI can significantly accelerate codebase discovery by mapping components, documenting existing behavior and explaining unfamiliar code. This lowers the risk of the “nobody understands it” systems from question 4.
- Routine translation is cheaper. Repetitive work, such as upgrading Drupal 9 custom modules toward Drupal 11 coding standards, moving old PHP to supported versions, or converting old Angular components, can often be accelerated through AI-assisted engineering.
- Tests come first. AI can help generate tests that capture how the existing system behaves, giving engineers a repeatable way to validate equivalent behavior in the modernized system.
What it does not change
- Complex business logic still needs people. A 2026 published case study migrated 12 features of a Visual Basic 6 business system to C# and .NET 10 with an AI coding agent. Simple features matched the original about 92% of the time; the most complex ones only about 47%, for an average of about 70%. AI does the first draft; engineers make it correct.
- Security-critical code, payment workflows and personal-data handling require rigorous human review and testing.
- Content, data and decisions (what to keep, what to drop) are still business work.
How OST uses it. OST uses AI-assisted engineering on modernization projects, with every change reviewed and tested by our engineers before release. This is why the starting prices in our free modernization calculator are lower than traditional estimates. The final price always depends on a review of your system.
Practical rule: treat AI as a fast, tireless junior engineer. Use it to read, draft and test. Keep experienced engineers responsible for design, review and anything that touches money, security or personal data.
8. Contract terms that protect the buyer
Write switchover and rollback into the contract, not just the project plan.
Buyer protection checklist
- Migration acceptance criteria, with record counts reconciled
- A tested rollback procedure
- Data ownership and export rights
- Documentation and knowledge transfer
- A post-launch support period
Sample clause: switchover readiness. “Switchover to production will proceed only after the Vendor has demonstrated, on a staging environment using a copy of production data: (a) a complete data migration with record counts reconciled; (b) all redirects in the agreed redirect map working; and (c) successful completion of the agreed acceptance checklist.”
Sample clause: rollback. “The Vendor will maintain the prior system in a deployable state for [30] days after switchover. If a severity-1 issue cannot be resolved within [4] hours, the Vendor will, at the Client’s request, restore service on the prior system within [2] hours at no additional cost.”
Sample clause: data ownership and export. “All Client data, content and configuration remain the property of the Client. On request, the Vendor will provide a complete export in an open, documented format within [10] business days.”
Sample clause: knowledge transfer. “Before final acceptance, the Vendor will deliver system documentation, deployment instructions and an administrator training session, and will provide [30] days of post-launch support.”
These are examples to discuss with your legal adviser. They are not legal advice.
9. Real-world example: rebuilding ost.agency in 2026
OST rebuilt its own website in 2026. We describe it here because we can share the details openly.
Where we started
- An Angular 18 site, statically generated and served through an Express server behind Apache, on a server shared with other OST sites.
- Releases were manual file uploads to dated folders. Quick fixes made directly on the server were lost at the next release, because the server, not the code, held the change.
- Content changes needed a developer.
- Performance checks in April 2026 placed many desktop pages in Google’s “needs improvement” range.
How the six-question test scored
| Question | Score | Why |
|---|---|---|
| Support | 1 | Angular 18 was still supported at the time (it has since reached end of life), but the release setup was fragile |
| Change speed | 2 | Simple content changes needed a developer and a manual release |
| Fit | 2 | No content management for marketing, tools and resources |
| Code health | 1 | Working code, but fixes lived on the server |
| People | 0 | Common technologies |
| Data | 1 | Content spread across code files |
| Total | 7 | Replatform, with the business logic carried over |
What we did
- New platform: a static Astro website with Payload CMS for content, so marketing staff edit pages without a developer.
- Code-first releases: every change goes through a pull request and review before a release, so fixes cannot be lost on the server.
- Repeatable migrations: database changes are scripted, and content was migrated by script, not by hand.
- Staging first: every change is tested on a staging copy before the live site.
- Redirect map: old addresses were mapped to new ones to protect search rankings.
What we learned
- Moving content was more work than building pages. Start the content inventory first.
- A staging server that matches live catches problems that local testing does not.
- Release scripts need as much care as the site itself. Our team found and fixed several gaps in the deploy script before they reached the live site.
10. A 90-day starting plan
| Days | Step | Deliverable |
|---|---|---|
| 1 to 15 | Inventory | List of systems, platforms, versions and support end dates |
| 16 to 30 | Score | Six-question score for each system and a first recommendation |
| 31 to 45 | Price | Filled-in 3-year cost model for the top 2 or 3 systems |
| 46 to 60 | Plan | Chosen option, migration pattern, redirect and data plan, rollback plan |
| 61 to 90 | First slice | One low-risk slice moved to the new platform, using the strangler pattern |
This is an example plan. Larger estates, regulated data and complex integrations take longer.
Not sure whether to refactor, replatform or rebuild?
OST can review your existing systems, score modernization risk, compare your options over three years, and create a practical first-slice migration plan, before you commit to a full rebuild.
- Estimate your project with the free modernization calculator: https://ost.agency/tools/
- Talk to us about a modernization review: https://ost.agency/contact/
About the author
Manish Mittal is Technology and Digital Solutions Leader at OpenSource Technologies (OST). He has 23+ years in technology and has been with OST since 2012. OST is a women-led, WBENC-certified digital engineering firm with 14+ years and 500+ projects delivered for ecommerce, public sector and nonprofit clients.
Sources
All accessed October 6, 2026.
- Microsoft .NET Blog, “.NET 8 and .NET 9 will reach End of Support on November 10, 2026.” https://devblogs.microsoft.com/dotnet/dotnet-8-9-end-of-support/
- Microsoft, “.NET support policy.” https://dotnet.microsoft.com/en-us/platform/support/policy
- PHP, “Supported versions.” https://www.php.net/supported-versions.php
- Adobe, “Adobe Commerce and Magento Open Source lifecycle policy.” https://experienceleague.adobe.com/en/docs/commerce-operations/release/planning/lifecycle-policy
- Drupal.org, “Drupal core release schedule” (Drupal 10 end of life and Drupal 12 release). https://www.drupal.org/about/core/policies/core-release-cycles/schedule
- US Government Accountability Office, GAO-25-107795, “Information Technology: Agencies Need to Plan for Modernizing Critical Decades-Old Legacy Systems,” 2025. https://www.gao.gov/products/gao-25-107795
- Martin Fowler, “Strangler Fig Application.” https://martinfowler.com/bliki/StranglerFigApplication.html
- Angular, “Versioning and releases” (support windows). https://angular.dev/reference/releases
- Node.js, “Previous releases” (release and end-of-life schedule). https://nodejs.org/en/about/previous-releases
- “Legacy System Modernization with Coding Agents: A Case Study,” arXiv:2608.28972, 2026. https://arxiv.org/abs/2608.28972