Moving a website without losing anything in transit
Website migration is the engineering of moving a site to a new platform, host or codebase: extracting and transforming content, rebuilding integrations, moving data, and executing a cutover that can be reversed if something goes wrong.
Most of a migration is not the new website. It is the content that has to come across in a usable state, the integrations that have to keep working, the data that has to arrive complete, and the hour of the cutover itself, which is where migrations either go quietly or become a very long evening.
Content is where migrations lose most of their time, and the cause is always the same: the old site's content was not as structured as anyone believed. Fields used inconsistently, formatting embedded in the text, images referenced by absolute URLs pointing at the old domain, and metadata stored in whatever plugin was installed in 2019. The second recurring failure is integrations, payment, CRM, inventory, email, discovered during cutover rather than inventoried before it.
When this work makes sense
Questions worth asking any supplier
Has anyone audited the actual state of the content, or is it assumed to be clean? It rarely is.
Is there an inventory of every integration? The ones nobody remembers are found at cutover.
What is the rollback plan, and has it been tested? An untested rollback is a hope.
Where do uploads and user-generated files live, and do they survive the move?
Who owns DNS, and how long is the TTL? A high TTL turns a five-minute cutover into a day.
Deliverables
Content audit establishing the real structure and condition of what is moving
Extraction and transformation scripts, re-runnable rather than one-shot manual work
Integration inventory with each item tested on the new platform before cutover
Data migration with record counts reconciled on both sides
Media and upload migration with references rewritten to the new location
A written cutover plan with sequence, timings, owners and a tested rollback
DNS planning including TTL reduction ahead of the move
Post-cutover verification covering forms, payments, logins and integrations
Built with
Process
Migrations here run at least one full rehearsal before the real cutover. We migrate everything into a staging environment, verify counts and behaviour, then do it again for real using the same scripts. A migration performed once, live, with manual steps is a migration whose failure modes are discovered at the worst possible moment. Scripted and rehearsed, the cutover becomes a sequence someone has already executed rather than a first attempt.
The standard nine stages, discovery, strategy, UX/UI, development, content and SEO, testing, launch, measurement and continuous improvement, apply to every project. The paragraph above is what differs for this one.
What moves the number
Pricing depends on scope, functionality, integrations and content requirements. These are the factors that change it most:
Lift and shift, rebuild, or staged migration
Lift and shift
Fits: Moving hosting or infrastructure with the same codebase
Limits: Carries every existing problem across unchanged
Full rebuild
Fits: Platforms that are unmaintainable or no longer fit the business
Limits: Largest effort, and content transformation is usually underestimated
Staged migration
Fits: Large sites where moving everything at once is too risky
Limits: Runs two systems in parallel for a period, with the complexity that implies
Case studies
No published migration case study. We would rather publish nothing than a description of a project we cannot name.
MBGDesk operates from 4 offices in India, United States, United Kingdom, United Arab Emirates. We hold no industry certifications and do not imply otherwise.
Frequently asked questions
How is this different from migration SEO?
This is the engineering: moving content, data and integrations onto a new platform and executing the cutover. Migration SEO is the search side, URL mapping, redirects, preserving rankings. They run together on the same project, and a migration that succeeds technically while losing every URL has still failed.
How much downtime should we expect?
It depends on the approach and what you are willing to pay to avoid it. A straightforward cutover with reduced DNS TTL can be minutes. Zero downtime is achievable and costs more, because it means running both systems and synchronising during the transition.
Will we lose our content?
Not if it is audited first. What clients do lose is content they had forgotten, old landing pages, PDFs, images referenced from elsewhere. The audit is what finds those, and it is the step most often skipped.
Can you migrate from a platform you do not normally work with?
Usually, since the work is extraction, transformation and loading rather than expertise in the old system. Where a platform has no export path we would say so before quoting rather than discovering it mid-project.
What happens to our email when we move hosting?
It is the most commonly forgotten item on a migration checklist. If email runs on the same provider as the site, changing DNS can break it. We inventory DNS records before the move for exactly this reason.
What if the migration goes wrong on the night?
You roll back, which is why the plan includes a tested rollback rather than a described one. Rehearsing the migration in staging first means the live cutover is a repeat of something that already worked.
Services that connect to this
Talk to us about this
Tell us what you are trying to build and we will come back with scope, approach and an estimate.