Modernization
Modernizing .NET and PHP systems in steps, not a risky rewrite
Existing .NET, PHP and JavaScript systems moved forward in steps: an audit, a written plan, tests around the behavior that matters, then one release at a time. Typical paths are .NET Framework to modern .NET, legacy PHP to a supported version and Laravel, and JavaScript to TypeScript, planned to keep the system in use.
- Typical timeline
- Planned in stages after an auditWith each stage scoped and quoted
- How it’s quoted
- IndividuallyAfter a 30-minute call
- Who edits it
- Your teamIn the same system, with tests and documentation added
- Stack
- .NET, PHP and JavaScript.NET Framework to modern .NET, legacy PHP to Laravel, JavaScript to TypeScript
In your name Accounts and repositories, from day one Yours The code and documentation, under the signed agreement
On this page
Support horizon
How much runway is left on what you run.
Each runtime’s published end of security support, on one timeline. Tick what you run and the rest steps back.
Tick what you run to see your nearest deadline.
Nearest deadline: PHP 8.1, ended 31 December 2025.
Nearest deadline: .NET 8 and .NET 9, security support to 10 November 2026.
Nearest deadline: PHP 8.2, security support to 31 December 2026.
Nearest deadline: .NET Framework 4.6.2, security support to 12 January 2027.
Nearest deadline: Windows Server 2016, security support to 12 January 2027.
Nearest deadline: PHP 8.3, security support to 31 December 2027.
Nearest deadline: .NET 10, security support to 14 November 2028.
Nearest deadline: PHP 8.4, security support to 31 December 2028.
Sources: PHP unsupported branches, .NET support policy, PHP supported versions, .NET Framework lifecycle, Windows Server 2016 lifecycle. Checked 7 October 2026. Timeline from 1 Jul 2026 to 1 Jul 2029.
Every date, SQL Server and Windows Server included: add them to your calendar (.ics) · Data: JSON, CSV · The full deadline table, with sources.
Is it the right call?
When it’s the right call
- A system the business depends on has become slow or risky to change
- It runs on a .NET Framework or PHP version that no longer gets updates
- The people who built it have moved on, and the knowledge left with them
- A full rewrite has been proposed and you want an honest second opinion
When it isn’t
- The system works, rarely needs to change and is still supported We’d suggest: Keep it, and revisit modernization when it has to change
- A proven product now does what the system was built to do We’d suggest: Move to that product, with integrations built around it
Sound like you? The first step is a 30-minute scoping call with the engineer who would lead the work.Request a scoping call
Two ways to start small
- Scoped and quoted on its own
Modernization audit
The code, dependencies, data, hosting and releases reviewed, the risks ranked in a written report, and a step-by-step plan. Nothing beyond the audit is committed until you decide to go further.
Start with an audit What the audit report contains See a sample report Not sure yet? Take the readiness check - Fixed scope, usually 2–3 weeks
Discovery sprint
Research into your users, systems and constraints, the architecture decisions written down, and a written plan and quote, yours to take to any team.
Start with a discovery sprint What the written plan covers
Standard equipment
What we usually hand over on a project like this. Your proposal lists exactly what’s included.
- .NET
- C#
- PHP
- Laravel
- JavaScript
- TypeScript
- Blazor
- AWS
- Azure
- Google Cloud
Modernization audit
Code, dependencies, data, hosting and the release process reviewed, with the risks ranked in a written report.
Step-by-step plan
What to keep, upgrade or replace, in order of risk and value, with each stage scoped before it starts.
A safety net of tests
Automated tests around the behavior that matters, added before anything is changed.
Upgraded system
Supported runtimes and frameworks, released in stages, with a way back at every step.
Documentation
Architecture notes, decision records and runbooks, so the knowledge no longer lives in one head.
Why steps beat a rewrite
Most systems worth modernizing are worth it because the business runs on them. That is also why a full rewrite is so risky: it throws away years of working behavior, including the edge cases nobody wrote down, and it usually takes longer than planned while the old system still needs care. Modernizing in steps keeps what works, fixes what doesn’t, and delivers value from the first release instead of the last.
How a modernization runs
- Audit. The risks ranked in a written report, after talking to the people who use and support the system, by video or on site in the Pittsburgh area.
- Plan. A step-by-step plan of what to keep, upgrade or replace, in order of risk and value. Each stage is scoped and quoted before it starts, so you can stop or change course between stages.
- Tests first. Before anything changes, automated tests go around the behavior that matters, so every later step can prove it hasn’t broken anything.
- Incremental replacement. Parts of the system are upgraded or replaced one release at a time (the approach often called the strangler pattern), often behind the same interfaces, so users and other systems see as little change as possible. Each release is planned with a way back.
What the audit report contains
- The system as it runs today: components, integrations, data stores and hosting, drawn and described.
- Support status: every runtime, framework and major dependency, and whether it still gets security updates.
- Changing it: how releases happen, what tests exist, and where a small change tends to break something else.
- Access and recovery: who can reach what, where secrets live, and whether a backup has ever been restored.
- Knowledge: what is written down, and what currently lives in one person’s head.
- Risks, ranked: each in plain language, with what it would cost the business if it happened.
- The staged plan: what to keep, upgrade or replace, in order of risk and value, with the first stage scoped.
The report is written for the people who decide as well as the people who maintain the system, so it can go straight to whoever signs off the next step. If you want a first read before talking to anyone, the readiness check asks about many of the same risks.
.NET Framework to modern .NET
Many .NET applications still run on the original .NET Framework. We move them to ASP.NET Core and current .NET in stages: separating what can move as it is from what needs rework, such as ASP.NET Web Forms pages, WCF services, Entity Framework 6 data access or abandoned libraries, and moving projects across one at a time with tests in place. Where a front end needs replacing, Blazor keeps it in C# for teams invested in .NET, or React, Vue or Angular when that fits better.
Still on .NET Framework 4.6.2? Microsoft support for that version ends on 12 January 2027; later 4.x versions stay supported with Windows. What to do before 12 January 2027 →
Still running servers on Windows Server 2016? Microsoft’s extended support for every edition ends the same day, 12 January 2027. Windows Server 2016: how to check and what to move to →
Already on .NET 8 or .NET 9? Microsoft support for both ends on 10 November 2026, and .NET 10 is the long-term support release to move to. Moving to .NET 10 before 10 November →
Legacy PHP, upgraded to PHP 8
PHP applications that have grown for a decade often lack tests, a dependency manager or a repeatable deployment. We bring them from PHP 5 or 7 to a supported PHP 8 release, introduce structure, often with Laravel, add tests around the important behavior and automate releases. The order follows risk, so the system becomes safer to change with every release.
Still on PHP 8.2? Its security support ends on 31 December 2026; PHP 8.4 is supported until the end of 2028. What to do before 31 December →
Beyond the back end
Modernization also covers JavaScript front ends moving to TypeScript, mobile apps that no longer build, and hosting that has outgrown a single server. Older infrastructure often moves to a documented cloud setup in your own account as part of the same plan. For new features on top, see custom web apps.
More in Custom software
SaaS platforms
Multi-tenant products with billing, roles and onboarding, designed so the second hundred customers cost less than the first.
Cloud & APIs
Infrastructure and APIs your software can rely on, in your own AWS, Azure or Google Cloud account, documented so anyone can run them.
Questions about modernization
Can we start with just the audit?
Yes, the audit can be a project on its own. It is scoped and quoted separately, and the ranked risks and step-by-step plan are yours to carry out with us, with your own team or with another one. Nothing beyond the audit is committed until you decide to go further. Not sure an audit is needed yet? Take the modernization readiness check first, at snowdriven.com/services/modernization/check/: ten yes-or-no questions, no email needed.
When is a full rewrite the right call?
A rewrite is the right call when the platform is truly at a dead end, the data model no longer fits the business, or the system is small enough to replace in a few weeks. If the audit points that way, we say so in writing and explain why, and the new build follows the same discipline: decisions written down, tests from the first commit and a planned cut-over.
Can our system stay in use while it is modernized?
We plan for the system to stay in use throughout; that is the reason we modernize in steps instead of rewriting. Where data has to move to a new component, the cut-over is planned in advance and each release has a way back.
How long does a modernization take?
It depends on the system, so we don’t guess before the audit. A long modernization runs as a series of short, finished stages rather than one open-ended project, each with its own timeline agreed before it starts. The first releases usually close the riskiest gaps, such as an unsupported runtime or releases done by hand.
Every build, any stack
One standard.
Performance
A performance budget is set before launch and enforced on every change.
Accessibility
Built to WCAG 2.2 AA and tested against it, with automated checks and manual keyboard and screen-reader passes on client builds.
Security
Least-privilege access, secrets kept out of code, dependencies monitored and security headers configured.
Handover
Accounts and repositories in your name from day one. The code and documentation are yours under the signed agreement, written so another team could take over.
Start a project
Tell us what it runs on.
The language, the version and what hurts today are enough to start. We reply within one business day, with questions or a time to talk.
Pittsburgh, PA · Since 2015 · First step: a 30-minute call