Website migration: how to move your site without turning the change into a problem

Changing platforms, redesigning a website or moving it to different hosting may seem like a contained technical task: copy the site, publish it and that is it. The problem arises when a page that was receiving visits no longer exists, a form stops sending enquiries or important content is left out of the new site.

A website migration involves moving a website —or part of it— from one environment to another without losing what must continue to work: content, URLs, data, functionality, access and integrations. By the end of this article, you will be able to identify what needs to be moved, what should be changed and when the project requires a technical review before publication.

How a website migration affects your business

The practical impact of a migration depends on what is changing. It may be as limited as moving the same website to new hosting, or as broad as replacing the content management system, reorganising sections, redesigning the interface and changing page paths.

The level of difficulty is not determined only by the number of pages. It is determined by the number of elements that depend on the website and by the consequences if any of them become unavailable or behave differently.

For example, a corporate website with information pages and a contact form mainly requires checks on content, page addresses and enquiry delivery. By contrast, if it includes a private area, shop, bookings, catalogue, languages or connections to other tools, the migration involves more data, rules and testing scenarios.

It is useful to separate three layers before deciding on a solution:

This distinction prevents the assumption that “building a new website” includes retaining everything that already exists. It also clarifies whether the objective is to update the brand image, make content easier to manage, fix technical issues or change a specific process.

How a website migration works

A migration is not usually a single move. It is the coordination of several changes that must work together.

First, the starting point is identified: which pages are published, what content exists, which functions each user uses and which external services are involved. The destination is then defined: the new structure, the technology that will host the website, the data that must be retained and the expected behaviours.

From there, each element follows one of these decisions:

• Retain: it moves to the new site with minimal changes.
• Transform: it is adapted to a new template, structure or format.
• Redirect: the previous address takes users to an equivalent new page.
• Remove: it deliberately ceases to exist because it no longer adds value or is replaced by other content.

A redirect is an instruction that sends someone requesting an old address to a new one. Its practical purpose is to prevent people from reaching a page that no longer exists when the information has moved. It should not be decided based on superficial similarity: the destination page must reasonably address the same need.

Components that need reviewing

A well-planned website migration treats the website as a system, not as a collection of screens. These are the usual components you should inventory.

URLs and navigation structure

Every page has an address. If the structure changes, you need to decide what will happen to each previous URL. This includes service pages, articles, categories, product pages, downloadable files and campaign pages that may still receive visits.

It is also worth reviewing menus, internal links, breadcrumbs and links in buttons. A page may exist but still be difficult to find if the new navigation does not integrate it properly.

Content and files

Text, images, documents, videos and metadata do not always transfer in the same way. Content may need cleaning, format adaptation or a new hierarchy before publication.

Do not assume that everything on the old site should be replicated. First decide which information is still current, who approves it and which content will be intentionally removed.

Data and users

When the website stores information, the migration may include form records, customers, orders, accounts, profiles or structured content. Here, both moving the data and preserving its meaning matter: a misinterpreted field, status or permission can affect subsequent operations.

If there are users with access, define which accounts will be retained, which roles they will have and how they will regain access if necessary.

Functions and integrations

A form, booking or payment is not merely a visual element. Behind it is a sequence of actions: a person enters data, the website validates it, it is sent to a destination and a confirmation or error is displayed.

Integrations are connections with external services, such as a payment platform, email tool or management system. Before migrating them, you need to know what information flows in and out, which credentials each connection uses and what should happen if the external service does not respond.

Infrastructure and access

The domain, hosting, certificates, technical accounts, backups and permissions are also part of the project. It is not just about “having access”: you need to know who controls each account, which access details are required and what dependency remains after launch.

The migration workflow: from inventory to verification

Order reduces uncertainty. Publishing first and then looking for what is missing usually makes issues harder to fix.

1. Define what must be retained and what must change

Start with the objective, not the tool. If the change aims to simplify content management, it may not be necessary to reproduce an old feature that no one uses. If the objective is to redesign the website without affecting commercial enquiries, the form and its user journey become a priority.

Classify each element as essential, desirable, future or out of scope. This prevents pending decisions from becoming omissions at the end.

2. Create a source inventory

The inventory brings together the elements that need assessment: URLs, content, files, forms, users, data, integrations, access and relevant configurations.

It does not need to be a complex document, but it must make it possible to answer a specific question: for each element, will it be retained, changed, redirected or removed?

3. Prepare the destination before making it public

The new website is configured in a working environment separate from the published site. This makes it possible to review the structure, content and functionality without interrupting normal access.

At this stage, approved elements are transferred and mappings are configured between old and new addresses. The required settings are also reviewed so that forms, notifications and external connections use the correct destinations.

4. Test user journeys, not just pages

Viewing a page correctly does not prove that the full function works. Check relevant actions from start to finish: submitting a form, signing in, completing a purchase where applicable, recovering access, viewing a page on mobile or receiving a confirmation.

Acceptance criteria help prevent ambiguous testing. For example: when a person completes a form correctly, they must see a visible confirmation and the enquiry must reach the designated recipient. If a required field is missing, they must receive a clear message and the enquiry must not be sent as valid.

5. Publish and review real-world behaviour

Going live is the point at which the new site becomes the one visitors see. After this change, it is advisable to check the most important routes, planned redirects, forms and integrations that depend on the published environment.

The post-launch review does not replace preparation, but it helps identify differences between the working environment and the now-accessible site.

Common limitations and failures in a migration

Not every risk can be eliminated with a copying tool. Some require content or business decisions, or clear responsibility for the data.

A common failure is to treat a migration as though it were only a visual change. If the structure is modified without mapping previous URLs, broken links or pages without a clear alternative may result.

It is also risky to move data without checking its quality and use. Duplicate records, fields without a defined meaning or incorrectly assigned permissions are not automatically resolved by moving them to a new platform.

Another limitation concerns integrations. A connection may depend on a particular account, permissions that have not been transferred or rules configured outside the website. Before changing it, you need to confirm who controls that dependency and what test demonstrates that it continues to work.

Finally, a backup is a recovery measure, not validation that the new site meets the objective. Being able to roll back does not confirm that the correct content is published, that redirects are appropriate or that important user journeys work.

When a website migration makes sense

It makes sense to consider one when changing the current site is necessary to support a specific need. For example:

• you are going to replace the content management system or hosting;
• the current structure prevents services, content or categories from being organised more effectively;
• the site needs to move to technology that supports defined functions;
• you need to retain content, data or URLs during a redesign;
• the current system depends on components you no longer wish to maintain.

Not every improvement requires a full migration. If the issue is limited to one page, one form or certain content, a targeted intervention may be sufficient. The decision depends on what needs to be corrected, which elements are connected to one another and what the consequences of changing the current foundation would be.

If you are not sure what needs to be retained, which URLs require an alternative or how to test critical user journeys, the next useful step is to explain the context before choosing technology. You can explore AVSISTEC’s web development service for businesses to plan a migration or website renewal project with the scope you actually need.