Moving Off an Old ASP.NET or Umbraco Site: WordPress, a Modern Stack, or an Upgrade

Why the old .NET site became a problem

Sites like this look alike when I open them. The site was built years ago by a developer or a small studio that has since moved on. It runs on a Windows server, the content team edits it through a back office nobody fully understands, and every small change needs someone who still knows C#. Nothing is broken today, but nobody wants to touch it, and that is the real cost: the business stops changing the site because changing it is risky.

I know these sites from the inside. I built on ASP.NET MVC for years, including the 2018 version of this site, which I rebuilt in 2020–2021 and moved to Next.js in 2026. That move taught me the same lesson as every client site: the pages are the easy part. The work is in what the site does behind them, and in not losing what Google already knows about it.

What "old" means in .NET, in dates

Not every old .NET site is unsupported, and it is worth being precise before anyone sells you urgency. Microsoft treats .NET Framework 4.x as a component of Windows: version 4.8 and later follow the support lifecycle of the Windows version they are installed on. A site on .NET Framework 4.8 on a supported Windows Server is still getting security updates for the framework. The modern line is different: .NET 8 and .NET 9 both reach end of support on 10 November 2026, and .NET 10, released in November 2025, is supported until 14 November 2028.

The trouble is moving forward. Microsoft's own migration guide opens by saying that updating an app from ASP.NET Framework to ASP.NET Core is non-trivial for the majority of production apps, and it lists why: code tied to System.Web, sessions and logins that work differently, old packages with no modern equivalent. Umbraco is the same story with a CMS on top. Its documentation says there is no direct upgrade path from Umbraco 8 to the latest version, because the underlying framework moved from ASP.NET to ASP.NET Core, and that all templates and custom code will need to be reimplemented. The content database can be migrated; the site cannot.

So for a site on Umbraco 7 or 8, or on an old Web Forms or MVC codebase, "just upgrade it" is also a rebuild. Once you accept that, the question becomes where to rebuild, and that is a business decision, not a technical one.

Three destinations, and who each one fits

I do not have a favourite here, and the table at the end of the article puts the three side by side. In short:

• Stay on .NET and rebuild on current Umbraco or ASP.NET Core: when you have .NET developers in-house, the site is tied to other .NET systems (an ERP, an internal API, single sign-on), or the content model in Umbraco works well and only the code is old.
• Move to WordPress: when the site is mainly content and lead forms, the people who edit it are not developers, and you want a large pool of developers and plugins to choose from, so that you are never again dependent on one person.
• Move to a custom modern stack, such as Next.js with a headless CMS: when the site is really an application, with logins, calculators, dashboards or heavy integrations, and you have a developer relationship that will last. It gives the most control and the best speed, and it asks for the most ongoing engineering.

The inventory: what the old site does that you cannot see

A custom .NET site hides its work in code, not in plugins you can list. Before anyone quotes a rebuild, someone has to open the code and the server and write down everything the site does. This list is where most surprises come from, and the cheapest week of the whole project.

• Forms and where each one sends its data: an email, a database table, a CRM, a spreadsheet.
• Integrations: payment pages, CRM or ERP connections, stock or price feeds, scheduled jobs that run at night.
• Logins: members, customers or staff areas, and what each role is allowed to see.
• Emails the site sends by itself: confirmations, reminders, password resets, and the mail server it uses.
• Rules hidden in server configuration: URL rewrites and redirects in web.config or IIS, which are easy to forget and decide what visitors land on.
• Content that lives in the database: pages, news items, team members, product lists, files and images on disk.

Moving the content

The good news about a database-driven site is that the content is structured, so it can usually be moved by script rather than by hand. On an Umbraco site, docs.umbraco.com describes migrating the content database to a newer Umbraco; for a move to another platform, the content is exported from the database (usually SQL Server) into files, cleaned, and imported. On WordPress that import can go through a plugin such as WP All Import, which imports CSV, XML, Excel or Google Sheets files into posts and custom post types, or through the WordPress REST API, which creates posts with a POST request to /wp/v2/posts. For a Next.js site, the same export goes into whatever content system the new site uses.

Two things are never automatic. Rich text from an old editor carries old HTML, inline styles and links to the old addresses; it has to be cleaned and its internal links rewritten. And this is the moment to delete: pages nobody visits and news from 2015 do not have to move. Search Console and analytics tell you which pages earn visits; those move with care, the rest are a decision.

Old .aspx addresses and Google

Old .NET sites have their own kind of addresses: page.aspx?id=123, folders that end in default.aspx, Umbraco paths built from the content tree. None of them will exist on the new site, and every one that returns "not found" gives up whatever ranking it had. Google's guide to site moves is clear about the fix: use server-side permanent redirects, such as 301 or 308, keep them for as long as possible, generally at least a year, and expect temporary fluctuation in ranking while Google recrawls the site.

• Build the list of old addresses from the sitemap, the server logs, Search Console and analytics, and include addresses with query strings if they get visits.
• Copy the redirects that already exist in web.config or IIS into the map, so old redirects keep working and do not become chains.
• Redirect each old address straight to its final new address. Google advises keeping chains short, ideally no more than three hops.
• Test the whole map on the new site before launch, and watch the "not found" report in Search Console for weeks after.

Forms, logins and integrations are rebuilt, not moved

Whatever the destination, the site's behaviour is written again. On WordPress, a form plugin plus a small amount of code usually replaces custom form handlers, and the CRM connection is rebuilt with the CRM's own plugin or an automation tool. On a modern stack it is code again, but current code, in a language more developers know. In both cases the new version is tested against the list from the inventory, one line at a time, with a real submission.

Member logins need their own plan. The old site stores passwords as hashes in its own format, and a new platform does not read them by default. Either every member sets a new password, which you announce in advance, or a developer writes a bridge that checks the old hash on each member's first login and saves it in the new format. The second option is more work and a smoother experience; for a large member base it is usually worth it.

The order of work

The old site stays live and untouched until the new one is ready. The new site is built on a temporary address closed to search engines, and the switch is a DNS change you can reverse.

• Inventory the code and the server, and agree on the list of what the new site must do.
• Choose the destination against that list, not against a preference for a technology.
• Export the content, clean it and import it into the new site on the temporary address.
• Rebuild forms, logins and integrations, and test each with a real submission.
• Write the redirect map and test it on the new site.
• Switch on a quiet day, submit the new sitemap in Search Console, and keep the old server available for a few weeks as a reference and a way back.

What drives the cost

I do not publish prices, because the honest answer comes out of the inventory. What I can say is what makes one migration small and another large. The project scope estimator gives you a first sense of the size, and every project gets a fixed quote after a short call. If you compare offers, the questions in my guide to red flags when hiring a WordPress developer apply, plus one: ask whether the quote includes the inventory and the redirect map, or assumes them.

• How much the site does beyond pages: forms, logins, integrations, scheduled jobs.
• How clean the content is, and how much of it moves.
• The number of page types and whether the design is kept or redone.
• The number of old addresses with traffic or links.
• Languages. A Hebrew and English site is two sets of content and a right-to-left layout to check.