When we first ran an AI-generated upgrade plan on a client’s .NET application, the build returned hundreds of errors, and our website modernization checklist starts with what that taught us. Here are the 12 things we now confirm before any upgrade begins, from the code to the infrastructure nobody wrote down.
Scope and ownership
The business problem, and today's baseline
Every modernization needs a written business reason and a set of numbers from today that you can compare against after launch. Name the problem in a sentence or two, for example, slow releases or a framework that no longer gets security fixes. Then record the baseline: page load times, error rates, monthly hosting cost, and how long a typical change takes to reach production. Without those numbers, it will not be possible to measure the success of the upgrade project.
Frontend and backend both in scope
Decide at the start whether the frontend is part of the upgrade. On our client project, the first plan covered the .NET backend only. We widened it to include the Angular frontend, and upgrading both together improved the overall performance and security of the application. A modern backend behind an outdated frontend still ships the old frontend code to every visitor's browser.
Who runs it after launch, and what it costs to run
A modernization project has an end date, and the system it produces needs an owner from the day after go-live. When the project team moves on, someone still has to apply security patches and respond when monitoring raises an alert. Name that person or team before work starts and write the support arrangement into the plan.
Patching is where an unclear owner costs the most. Verizon’s 2026 Data Breach Investigations Report found that 31% of breaches started with the exploitation of a vulnerability, making it the most common way in for the first time in the report’s 19 years. Verizon also reports that attackers use AI to exploit known vulnerabilities faster, shrinking defenders' response time from months to hours. A new platform launches fully patched and stays that way only while someone owns the updates.
The running cost also changes shape. An older website on a fixed hosting plan costs the same each month, while cloud hosting is billed by usage, so the bill moves with your traffic and the services you switch on. In Flexera’s 2026 State of the Cloud survey of more than 750 cloud decision-makers, 85% named managing cloud spend as a top challenge, and Flexera reported wasted cloud spend rising to 29%, the first increase in five years.
Ask for a running-cost estimate as part of the plan, and set a budget alert in the cloud account. Agree who signs off when that estimate changes.
Login access to every account
Before any work starts, confirm that someone at your company can log in to every account the website depends on. A modernization changes DNS records at cutover, and every new certificate needs proof that you control the domain, so the project stalls the first day nobody can get into the registrar or DNS provider. That access stays necessary after launch too. Under the CA/Browser Forum’s Ballot SC-081v3, the period a certificate authority may reuse domain validation data shrinks from 398 days to 10 days by March 2029.
Ownership matters as much as the password. ICANN states that it does not have “the ability or authority to transfer or return a domain name to anyone,” so a domain registered in a former agency’s or employee’s name can take negotiation or legal action to recover. ICANN’s Security and Stability Advisory Committee warns that losing control of DNS settings can disrupt a company’s “web or email” services, and recommends checking whether departing employees still have access to registration accounts.
The list covers the domain registrar, the DNS provider, the hosting or cloud account, the CDN, and third-party services such as payments and analytics. Confirm that your company is the named registrant on the domain. Store every login in your company’s password manager under a shared owner, and remove access for anyone who has left.
Infrastructure dependencies nobody wrote down
DNS records for email and certificates
Your domain's DNS records usually do more than point visitors at the website, and a migration that rebuilds DNS can break the other jobs they do. Email authentication is the first thing to protect. Google's email sender guidelines require everyone sending to Gmail to set up SPF or DKIM, and senders of 5,000 or more messages a day need SPF, DKIM, and DMARC. Export the full DNS zone before you change anything, and test outgoing email after every change.
TLS certificates need the same care. Under a CA/Browser Forum ballot, maximum certificate lifespans dropped to 200 days in March 2026, fall to 100 days in March 2027, and reach 47 days in March 2029. Any certificate still renewed by hand needs automatic renewal on the new platform.
Scheduled jobs, integrations and hard-coded settings
List every scheduled job, background task, and integration before you plan the move. Older servers may run cron jobs or Windows scheduled tasks that send reports or sync data with another system, and nobody remembers them until they stop. Search the code and the server configuration for hard-coded IP addresses and connection strings as well. Each one becomes a setting to move or a dependency to rebuild.
Runtime and framework end-of-life dates
Check the support dates for every runtime and framework the site uses, because a version past end of life stops receiving security fixes. Several of those dates fall in the last weeks of 2026. Microsoft’s .NET support policy lists 10 November 2026 as the end of support for both .NET 8 and .NET 9. Angular’s release schedule ends long-term support for Angular 20 on 28 November 2026, and the PHP project ends security support for PHP 8.2 on 31 December 2026.
If your site runs on any of these, the deadline for your modernization has already been set. Choose a target version with years of support left on the day you go live, such as .NET 10, which Microsoft supports until 14 November 2028, or Angular 22, with long-term support until June 2028.
Backups you have restored, and a rollback plan
Confirm that your backups work by restoring one to a test environment before the project starts. A backup nobody has restored is an untested assumption. Write down the rollback plan for cutover day too, including how long the business can tolerate downtime and who decides to roll back. Keep the old environment running until the new one has handled real traffic for an agreed period.
Code readiness
Unit tests written before the migration starts
Make sure the legacy application has unit tests for the modules the upgrade will touch, and get them written before any code changes. The tests record how the system behaves today, so after each step of the migration you can run them again and see straight away what has changed. Our client’s application had modules without tests, and we added them ahead of the migration. Those tests made testing after the migration far easier.
If your own team lacks the time or the skills to write them, make test creation part of the vendor’s scope. Put it in the statement of work as the first deliverable, and ask to see the tests pass against the current system before the upgrade begins. Agree that the same tests run after every phase of the migration, and that you receive them with the rest of the code at handover.
Dead code removed and duplicates consolidated
Delete unused files and code before you upgrade, so the team spends no time migrating things nobody uses. We did this on our client project, and it gave us a cleaner codebase to modernize. Legacy applications also tend to repeat the same logic in many places, with few shared components or functions. We made converting that duplicate code into shared functions and components part of the plan, so the upgraded application is easier to maintain.
Search traffic and the plan
A complete map from old URLs to new ones
Map every old URL to its new address before launch, and send each one through a permanent redirect. Google's site move guidance recommends server-side 301 or 308 redirects and keeping them in place for at least a year. Google also says to expect temporary ranking changes, and that for a medium-sized site it can take a few weeks or more for new URLs to replace old ones in results. Build the list of old URLs from your analytics and Search Console so every page with traffic or backlinks is covered.
A plan that people have reviewed, split into small phases
An AI-generated migration plan should always go through a human review before execution. AI agents can create a strong starting point, but the plan still needs to be validated against the application’s architecture, dependencies, package versions, custom code and the right upgrade sequence.
This review is especially important for complex upgrades such as .NET modernization. A single incorrect package update, namespace change or dependency assumption can create cascading build errors across a solution. Catching these issues in the plan before any code is changed is much faster and less expensive than diagnosing hundreds of related errors afterward.
A thoughtful review also helps identify unnecessary or incorrectly ordered steps early, reducing development time, AI usage costs and rework. The goal should not be to slow down the AI agent, but to make sure it starts with the right plan.
Ready to pinpoint critical gaps and build a modernization roadmap? Our Legacy App Modernization Services team can help.
