Your website is built in .NET, maintained by very few people, and each change costs more than it should. This page explains how to move such a website to WordPress: what gets moved, what happens to its search engine addresses, and what happens to forms and custom functionalities.
Your website is built in .NET, maintained by very few people, and each change costs more than it should. This page explains how to move such a website to WordPress: what gets moved, what happens to its search engine addresses, and what happens to forms and custom functionalities.
To start, just describe the website. Do not send credentials or databases.
Request your Proportione Legacy diagnosis
Each query has its section, with its own questions:
An ASP.NET website usually mixes four things: content (pages, news, documents, images), design, functionalities (forms, search engines, private areas), and connection with other company systems. Migrating it to WordPress means deciding what to do with each part, not just changing one site for another.
Content and design are the most defined parts: they are extracted from wherever they are (the database or the site's files) and moved to WordPress pages, posts, and templates. Functionalities and connections are the parts that require analysis.
We start with a diagnosis of your data and processes before choosing the destination. It delivers an inventory of processes and data, the options (build, buy, or connect), and a phased scope proposal.
| Part of your .NET website | What is decided during migration | |---|---| | Pages, news, and media | They are extracted and moved to WordPress with their structure. | | Design and templates | They are redone as a WordPress theme, starting from what already works. | | Addresses (URLs) | They would be invented and redirected one by one. See the next section. | | Forms and private areas | They are reviewed one by one. See below. | | Connections with other systems | They are kept connected or redone; decided in the diagnosis. |
When WordPress is not the answer. If what you have is not a content website but an application with its own business logic, the right destination may be another. That conversation is in custom software development. If that application is built on an unmaintained framework, see a custom or unmaintained framework.
What it means for you: you know which pieces travel as-is and which need to be decided. Next step: describe to us what your website does besides displaying content.
A .NET website usually has addresses with its own format (for example, ending in `.aspx` or with parameters). In WordPress, addresses are constructed differently. If not handled carefully, search engines and links from other websites will stop finding what they previously found.
When migrating a content management system, we take inventory of URLs, 301 redirects one by one, preservation of what already works, and verification after the change. On a .NET website, this translates in the following order:
1. URL Inventory. All existing addresses are gathered: those from the sitemap, from analytics and Search Console, and those receiving links from other websites. 2. 301 redirects, one by one. Each old address is associated with its new equivalent. What no longer has an equivalent is intentionally decided, not by omission. 3. Preservation of what already works. Titles, descriptions, and headings that currently serve their purpose are transferred to the new platform. 4. Post-launch verification. Response codes for the inventory URLs, the new sitemap, and performance trends in Search Console are verified.
It's a method, not a guarantee: no migration can promise that the ranking will remain identical. What can be done is to measure before, proceed with criteria, and verify afterward.
What it means for you: you have the list of what is being moved and how it is verified right in front of you. Next step: tell us approximately how many pages your website has and if you retain access to analytics.
This is the part that requires the most analysis. The content is moved; what the website does must be understood before moving it.
Each form is reviewed: what data it collects, where it goes, and who receives it. A simple contact form has a direct equivalent in WordPress. One that writes to a database or another system is treated as a connection.
If the website requires a username and password, the diagnosis determines who logs in, what they see, and where those accounts currently reside. Credentials are not migrated blindly: the transfer or renewal method is agreed upon in advance.
Internal search engines, calculators, catalogs with custom rules, downloads with access control. For each one, there are three paths, the same ones used throughout the method: build a custom component within WordPress, buy an extension that already solves it, or connect the existing function so that WordPress consumes it. It is chosen piece by piece, with good judgment.
We have migrated an old .NET website to WordPress. We provide no further details of the case to avoid identifying the client.
What it means for you: knows in advance what is being rebuilt and what is being preserved. Next step: make a list of the forms and features your website currently has, even if incomplete.
Whatever the destination, the method is the same. The general details are in how we work.
1. Diagnosis: process and data inventory, options (build, buy, or connect), and phased scope proposal. 2. Scoped pilot, with pre-established acceptance criteria before proceeding, when the case requires it. 3. Phased delivery, with acceptance criteria and a rollback plan. 4. Handover: verifiable documentation, export, and custody. The code belongs to the client, and that is how it is stated in the contract.
What it means for you: at all times you know what has been delivered, what is missing, and how to roll back. Next step: request the diagnosis.
The order is always the same: first, the process is digitized and understood; then, the old software is opened with APIs and connectors to link it with the rest, and only then is AI considered on top. AI can run on its own server and, if necessary, without an internet connection. This is the option we describe in legacy systems migration service and in artificial intelligence in business.
If your website is just one piece of a set of legacy systems, see the overview in Business Management Consulting and in our services.
With a diagnosis of your data and processes, before choosing a destination. It delivers an inventory of processes and data, the options (build, buy, or connect), and a phased scope proposal.
We cannot promise that rankings will remain identical. What we do is inventory URLs, implement one-to-one 301 redirects, preserve what already works, and run checks after the change.
They are reviewed one by one. A simple contact form has a direct equivalent; one that writes to another system is treated as a connection, and a private area is agreed upon before moving anything. This is explained in the section on Custom forms and functionalities.
It is a common destination for content websites, but not the only one nor the right one in every case. The diagnosis compares options based on who publishes content, what features are needed, and which systems it must connect to.
It depends on the scope: how many pages and types of content there are, which functions are being redone, and which systems it connects to. The diagnosis ends with a phased scope proposal, and based on that, it is finalized. We do not provide a figure or a deadline without knowing your case.
The code belongs to the client, and this is explicitly stated in the contract. Documentation, exportability, and custody are verifiable and form part of the design.
Tell us what website you have and what you need. We will respond within a maximum of two business days. You also can write to us from contact. [Short form: see specification in notes]
Request your Proportione Legacy diagnosisDo not send credentials or databases. We will use your data only to respond to you; more information in the Privacy Policy.
