The first 90 days of a legacy .NET modernisation programme should not be spent rewriting code. They should be spent reducing uncertainty, protecting critical behaviour and identifying the smallest changes that can prove the modernisation strategy.
This roadmap is designed for CTOs, Heads of Engineering and Engineering Managers responsible for business-critical .NET estates where delivery risk matters as much as technical improvement.
Days 1–30: establish the evidence
Start by understanding the platform as it operates today. Inventory runtimes and dependencies, map critical customer and operational journeys, identify key integrations and scheduled processes, and establish where knowledge is concentrated.
- Identify unsupported or high-risk technology.
- Map the business journeys the organisation cannot afford to break.
- Baseline deployment frequency, incident rates and support effort.
- Document known architectural bottlenecks and shared-data dependencies.
- Capture current test, telemetry and rollback capability.
The goal is not a perfect architecture document. It is enough evidence to distinguish genuine business risk from technical preferences. The Legacy .NET Modernisation Checklist can structure this initial assessment.
Days 31–60: protect behaviour and choose boundaries
Once the highest-risk journeys are visible, improve the safety net around them. Characterisation tests, integration tests and production telemetry can make hidden behaviour observable before it is moved.
At the same time, identify candidate boundaries for incremental change. Good candidates have understandable inputs and outputs, clear business value and enough independence to be changed without moving the entire platform.
- Protect critical calculations and workflows with repeatable evidence.
- Find seams around high-change or high-cost capabilities.
- Decide which components should be retained, upgraded, wrapped, extracted, replaced or retired.
- Validate data ownership and integration assumptions.
- Choose one or two candidate changes that can demonstrate the strategy.
Days 61–90: prove the route
The final month should turn analysis into evidence of delivery. Implement a deliberately bounded improvement: an API around a legacy capability, a service extraction, a deployment improvement or a runtime migration for a well-understood component.
Where possible, run old and new behaviour side by side. Measure whether the change actually improves lead time, supportability, deployment confidence or operational visibility.
What you should have after 90 days
- A risk-based view of the estate rather than a technology inventory alone.
- A map of business-critical journeys and their dependencies.
- Improved protection around the behaviour most likely to block change.
- A prioritised modernisation roadmap with explicit sequencing.
- Evidence from at least one bounded modernisation change.
- Clearer estimates for the investment and organisational capability required next.
What not to do in the first 90 days
Avoid committing the entire estate to microservices, cloud migration or a full rewrite before the boundaries are understood. Avoid measuring progress by lines of code converted. And avoid treating discovery as a phase that ends: every extracted capability will expose more about the system.
If the organisation is still debating whether the platform should be rewritten at all, start with Rewrite or Modernise?. If you already know staged modernisation is the right direction, the modern .NET migration guide goes deeper into the engineering sequence.
Need an independent starting point?
My legacy .NET modernisation work helps engineering leaders turn an uncertain estate into a practical, staged roadmap before major budget is committed.
