“Website migration” is one of those phrases that becomes almost meaningless until you ask what is actually moving.
A Nigerian hosting company may move a WordPress site to its server for free. A freelancer may charge ₦100,000 to transfer a site and email. A business may receive a ₦2 million quote to move from an old CMS to a modern stack while preserving content, URLs, forms, analytics and search visibility.
All three can honestly be called migration.
They are not the same project.
For 2026 planning, these are the budget bands I would use before seeing the site:
| Migration type | Planning budget | Typical scope |
|---|---|---|
| Same-platform hosting move | ₦50,000–₦200,000 | Copy site/database, configure new host, test, switch DNS |
| CMS/content migration | ₦250,000–₦800,000 | Move content/templates/configuration between systems with moderate cleanup |
| SEO-sensitive redesign or replatform | ₦700,000–₦2.5 million | New platform or major rebuild, URL mapping, redirects, content and conversion preservation |
| Ecommerce / integration-heavy migration | ₦1.5 million–₦5 million+ | Products, customers, orders, payments, search, integrations, richer QA and launch controls |
| Custom application migration | Scope-dependent | Data model, user accounts, workflows, APIs, infrastructure and operational cutover |
These are planning ranges, not an official Nigerian market tariff.
The useful first question is:
Are you moving the same website, changing the platform, or changing the product while you move?
That answer explains most of the price difference.
Why a hosting move can be free while a migration project costs millions
Some Nigerian and international hosting providers currently advertise free migration when you buy their hosting.
That can be perfectly legitimate because the commercial model is different: the provider wants your recurring hosting account and may have tooling for moving a compatible WordPress or cPanel setup.
The transfer may include:
- site files;
- database;
- email accounts;
- basic configuration;
- SSL;
- DNS cutover assistance.
What it normally does not mean is:
- redesign the site;
- change the CMS;
- rewrite the information architecture;
- create a new URL structure;
- rebuild custom integrations;
- fix historical SEO problems;
- migrate complex customer/order data;
- improve conversion journeys;
- rebuild old functionality that does not exist on the destination platform.
So do not use a host’s “free migration” offer as the reference price for a replatforming project.
You are comparing file transfer with system change.
Migration type 1: same website, new hosting
This is the simplest migration.
The visible URLs stay the same. The design and CMS stay the same. The business is changing the infrastructure that serves the website.
Google has a dedicated guide for exactly this case: a hosting infrastructure change where user-visible URLs do not change.
Its recommended sequence is straightforward:
- prepare the new hosting environment;
- copy and thoroughly test the site;
- make sure Googlebot can access the new infrastructure;
- preserve Search Console verification;
- lower DNS TTL in advance when appropriate;
- change DNS;
- monitor traffic and crawling on the old and new environments;
- shut the old infrastructure down only after the move is clearly complete.
Source: Google Search Central: Changing your hosting.
The important point is that even the “simple” migration is not just uploading a zip file.
A responsible quote should account for validation.
What I would test before switching DNS
At minimum:
- homepage and representative page templates;
- forms;
- images and downloadable files;
- login or account areas if present;
- database writes;
- transactional email;
- redirects;
- HTTPS;
- scheduled jobs;
- payment or booking integrations;
- robots and indexing directives;
- analytics;
- performance and server errors.
The more of those your website has, the less useful a flat “migration fee” becomes without written scope.
Migration type 2: moving to another CMS or platform
Now the work becomes more expensive because a page is no longer simply a file to copy.
A page may need to be transformed from one system’s content model into another system’s model.
For example:
- Wix to WordPress;
- WordPress to a headless/static stack;
- old custom PHP to a modern framework;
- one ecommerce platform to another;
- a page-builder site into a maintainable component system.
The project can require:
- content inventory;
- data export/import;
- template recreation;
- image/file migration;
- metadata migration;
- URL preservation or mapping;
- form reconstruction;
- analytics and tag migration;
- redirect rules;
- integration replacement;
- editor training;
- staging and QA.
At this point the word replatform is often more accurate than “transfer.”
That is why I would not quote this work from page count alone.
Ten pages with a booking engine, member area and years of indexed content can be riskier than fifty static pages.
Migration type 3: redesign while migrating
This is where buyers often underestimate the scope.
They say:
We only want to move from the old website to the new one.
But the new website has:
- different navigation;
- different page names;
- fewer pages;
- new copy;
- a new CMS;
- changed service structure;
- new forms;
- new tracking;
- new hosting.
That is not one change. It is several changes happening at the same commercial moment.
Google’s site-move documentation advises changing one thing at a time where practical because combining domain, CMS and layout changes makes diagnosis harder if search performance moves unexpectedly.
Source: Google Search Central: Site moves and migrations.
Sometimes the business still needs to combine them. A legacy platform may make staged changes uneconomical.
If so, the migration budget should include enough pre-launch inventory and post-launch monitoring to compensate for the increased risk.
If URLs change, URL mapping becomes part of the product
When an indexed URL changes, the migration needs a defined destination for the old address.
Google recommends preparing a mapping from old URLs to their corresponding new URLs, updating internal links and canonical annotations, and using server-side permanent redirects where possible.
Source: Google Search Central: Prepare URL mapping and redirects.
For a serious migration, I want a table before launch that answers:
| Old URL | New URL | Action |
|---|---|---|
/old-service |
/services/current-service |
Permanent redirect |
/obsolete-offer |
Most relevant replacement | Redirect only if intent genuinely matches |
/old-campaign |
None | Intentional 404/410 if there is no useful replacement |
/high-traffic-guide |
Same or equivalent guide | Preserve closely |
The lazy approach is redirecting every old page to the homepage.
That hides 404s without preserving the user’s intent.
A migration should protect meaning, not merely avoid error pages.
Why SEO-sensitive migration costs more
If the current website has search visibility, links and traffic, the migration has assets to preserve.
The project should normally include some combination of:
- crawl of the old site;
- sitemap export;
- Search Console review;
- analytics landing-page review;
- backlink-aware priority pages;
- canonical review;
- URL mapping;
- redirect implementation;
- internal-link update;
- new sitemap;
- robots/noindex checks;
- structured-data validation where relevant;
- launch monitoring;
- post-launch crawl and error review.
Google notes that search visibility can fluctuate temporarily during a site move and that processing can take weeks for a small/medium site, depending on site size and server speed.
It also recommends keeping redirects for as long as possible, generally at least one year, to allow signals to transfer.
Source: Google Search Central migration guidance.
The migration fee is partly paying someone to make that transition observable rather than mysterious.
Ecommerce migration is a data project, not only a website project
An ecommerce migration becomes expensive when historical and transactional data matter.
You may need to preserve or deliberately transform:
- products and variants;
- categories/collections;
- stock;
- customers;
- orders;
- discount codes;
- tax settings;
- shipping rules;
- product URLs;
- reviews;
- images;
- payment configuration;
- transactional emails;
- analytics events;
- search/filter behaviour.
The difficult question is often not “can the data be imported?”
It is:
Does the destination system represent the same business rules?
If not, the migration needs explicit transformation logic and reconciliation.
That is software work.
Website migration cost should include a recovery plan
I do not consider a migration properly scoped if the only launch plan is:
switch it and see what happens.
Before cutover, define:
- current backup;
- old environment retention period;
- final content/data sync window;
- who changes DNS;
- who verifies production;
- acceptable outage window;
- rollback criteria;
- rollback method;
- post-launch monitoring owner.
For a normal hosting move, Google itself recommends monitoring both old and new infrastructure and shutting the old hosting down only when traffic has clearly moved and the new setup is working.
That is a good operational principle beyond SEO too.
Do not destroy your fallback before you have proven the replacement.
Hidden migration costs to ask about before accepting a quote
If your current host also runs company email, changing hosting can accidentally become an email migration.
Confirm whether mailboxes, DNS records, historical messages and deliverability configuration are included.
Premium licences
The new stack may require themes, plugins, SaaS subscriptions, search services, CDN or monitoring that the old quote did not include.
Content cleanup
Migration is the moment businesses discover years of duplicate pages, oversized images and content nobody owns.
Decide whether the provider is migrating everything or curating what deserves to survive.
Redirect implementation
A spreadsheet of redirects is not the same as working redirects in production.
Make sure implementation and testing are included.
Analytics and ads
A new template can lose analytics tags, ad pixels or conversion events even while the pages look correct.
Forms and transactional email
A form visually surviving migration does not prove its messages are reaching the business.
DNS and domain ownership
If the old developer controls the registrar or DNS account, access recovery can become the real migration blocker.
Post-launch fixes
Ask how long the migration warranty or stabilisation period lasts and what counts as a migration defect versus new feature work.
When to migrate instead of rebuild
I would lean toward preserving the current site when:
- the information architecture still makes sense;
- the content is useful;
- the conversion journey works;
- the main problem is hosting, reliability or platform limitations;
- the design can survive the move;
- the business has valuable URLs and search visibility;
- the code/CMS is maintainable enough to keep.
In that case, spend on a controlled migration rather than paying to recreate value you already own.
When migration should become a rebuild
A rebuild becomes more credible when:
- the current site is structurally difficult to edit;
- the service/product architecture has changed;
- the mobile journey is fundamentally weak;
- key integrations are brittle or obsolete;
- the website cannot support the business’s next workflow;
- the existing templates cannot be made performant economically;
- ownership is so fragmented that maintaining the old foundation is more expensive than replacing it.
My repair, redesign or rebuild guide handles that decision in more detail.
The key is not to hide a rebuild inside a migration quote.
Name the project accurately so you can compare scope accurately.
How to compare website migration quotes in Nigeria
Ask every provider to answer the same questions:
- Is this a hosting move, CMS migration, replatform or rebuild?
- Are visible URLs changing?
- Who creates the old-to-new URL map?
- Who implements and tests redirects?
- Are Search Console and analytics part of the migration review?
- What content/data is moving?
- What will be rebuilt manually?
- Which integrations are included?
- Are email and DNS included?
- Is there a staging environment?
- What is the backup and rollback plan?
- How is the final data/content sync handled?
- What is tested before DNS/cutover?
- What is monitored after launch?
- How long does post-launch support last?
Now a ₦150,000 quote and a ₦1.5 million quote can be compared on responsibility rather than headline price.
The cheapest migration is the one that does not throw away working value
The goal is not to move files.
It is to transfer the business value attached to the old website into a new operating environment with as little avoidable loss as possible.
That value can include rankings, links, customer trust, content, analytics history, forms, booking flows, product data and domain authority.
If your move is SEO-sensitive, use my website migration SEO checklist before approving the cutover. If you need the migration scoped and executed as part of a broader rebuild or platform change, see my web design service or send me the current site, destination and reason for moving.
I can help separate what can be transferred cheaply from what actually needs engineering, redesign or SEO-preservation work—before the project becomes an expensive surprise.
