What is the cost of website migration?

What drives website migration cost?

Migration pricing varies widely because no two projects carry the same work. Moving a brochure site demands far less effort than moving a platform with custom features, integrations and thousands of URLs. The cost scales with structural complexity and with how much of the current functionality a developer has to write again on the new stack, so the estimate is only as good as the inventory behind it.

Website Size and Structural Complexity

Total content volume is one of the primary cost drivers in any website migration. A small site is naturally easier to move than a property housing hundreds of pages. Complex taxonomy and deep URL structures require careful mapping to preserve user experience and data integrity. Transitioning a large architecture means developers spend more hours ensuring every asset lands in the correct directory.

Functionality and Custom Integrations

Website functionality directly dictates the technical effort required. Basic features usually transfer without issue, but custom functionality and specialized integrations require thorough compatibility checks. If the current setup relies on bespoke APIs, complex user databases, or unique media handling, developers must adapt those connections for the new environment. Every additional integration adds another layer of testing to the project scope.

Platform-Specific Variables

Moving between different content management systems introduces specific technical hurdles. Higher WordPress migration costs, for example, frequently stem from transferring custom themes, templates, blocks, and plugins. Developers must also migrate short codes, custom post types, fields, user data, forms, and advanced search configurations. Unique hosting behaviors further complicate the transition, demanding specialized knowledge to prevent downtime.

Redesign Scope and SEO Protection

Updating the visual design at the same time as a platform move stretches both timelines and budgets. Factoring in SEO work also influences the final bill, as specialists must perform a full website migration audit. Planning a careful 301 redirect setup ensures the domain maintains its search visibility after launch. Each of these is a line somebody has to estimate, and each one is a place where two proposals stop being comparable.

How much does website migration cost?

A migration is priced by scope rather than by a rate card, so the honest answer starts with what sets the number: how many URLs move, how much of the functionality survives the move and how much is written again, and whether the design is redone at the same time. Agencies quote it one of two ways, as a fixed price agreed after an assessment, or as time and materials against an hourly or daily rate. Both resolve to the same arithmetic in the end, which is hours multiplied by a rate, and both halves of it are below.

Most migrations land between 400 and 600 hours. What moves a project inside that band is the inventory: the number of URLs, the templates, the integrations and how much of the functionality is written again rather than carried over. What moves the price is where the team sits.

Those are planning bands rather than quotes: they tell you which order of magnitude the conversation is in, and whether the proposal in front of you is in the same one. They also assume the work is done by hand. Teams using AI tooling are delivering these migrations around 50% faster, which is how Pagepro builds its Nexity migrations: the same scope, roughly half the hours, so halve the bands above and you have the other end of the market.

What a Small Site Move Includes

Simple sites with minimal content sit at the lower end of the scale. A brochure site of a dozen or so pages, with stock templates and no custom features, is mostly content transfer, a redirect map where old and new URLs match one to one, and a round of checks. There is little to rebuild, so the hours are few and predictable, which is why this is the tier where a fixed price on a clearly defined scope is easiest to agree and hardest to blow.

What a Large Site Move Adds

Scaling up the architecture adds the work a small site never had. Thousands of URLs mean the redirect map stops being a one-to-one list and becomes a set of decisions about pages that merged or disappeared. Custom functionality comes across as a specification to build and test, not as an export, integrations have to be reconnected, and the rollout is staged instead of switched. Each of those is hours, which is why the same job can cost an order of magnitude more on a large estate than on a brochure site, and why a solid SEO migration budget is what protects existing search rankings while all of it happens.

What makes an estimate realistic is the inventory behind it, not the bracket it lands in. Count the URLs, the templates and the integrations first, and the number follows from work somebody can point at. For what agencies in this market publish as their own starting points, our comparison of CMS migration providers lists them side by side.

What This Looked Like on Real Projects

Three Pagepro migrations, one per tier, with the shape of the team and the time they took. Multiply the team by the rate you pay and you have the band your own project sits in.

The numbers behind those rows: Darktools came out of its four weeks with Lighthouse at 92 on mobile and 99 on desktop, up from 45 and 83. Localcoin’s site carries around 5,900 URLs, including 2,600+ programmatic ATM-location pages across 7+ language variants. Learn Squared’s launch downtime stayed under four hours.

Four weeks, three months, six months. That is the real spread between a fixed-scope rebuild and a legacy exit, and it is set by how much of the site has to be built again instead of moved.

Turning an Inventory Into a Number

Take a site with 500 URLs, a dozen templates and three integrations, quoted at 400 hours, the lower end of the band above. Multiply the hours by the rate for wherever the team sits and you have the price. Then split the hours across the phases below to see whether the quote is balanced, because a total can be right while the shape behind it is wrong.

At the shares this article uses, those 400 hours come out as 40 to 60 on audit and planning, 60 to 80 on content, 140 to 180 on the build, 40 to 80 on quality checks, 20 to 40 on redirects and 20 to 40 on deployment and go-live. On the midpoints that is exactly 400, which is the point: every hour lands in a phase, and a 600 hour project stretches the same shares by half. Now compare it with the proposal in front of you. If the audit of a 500 URL site is quoted at 20 hours, the decisions about which of those URLs merge, retire or move are not being made by anyone, and that is where a migration is won or lost.

What are you paying for in migration?

Two proposals for the same migration can differ by a factor of three, and the difference is rarely the rate. It is how many people are billed and how much of the actual work sits inside the headline number. The shape below is what lets you read a proposal: if a phase is missing from the quote, it is not missing from the project, it is just being paid for later.

Budget Distribution Across Stages

Breaking down the total migration cost reveals a logical sequence of investments that guide the project from start to finish. The sequence starts with the audit and the inventory, because everything after it is priced from what they find; the test migration in staging comes later, but it is never optional, since it is what catches the errors before live users do. The shares below are planning assumptions rather than measurements, and they are written to add up: on their midpoints they come to 100% of the project. Use them to sanity-check a proposal, then replace them with the hours your own quote names.

• Audit and planning: 10 to 15% of the budget for the crawl, the URL inventory and the keep, merge or retire decision behind every template.
• Content migration: 15 to 20%, scripted where the content follows a pattern and hand-checked where it does not, which is the part that scales with volume.
• Build or rebuild: 35 to 45%, the largest line on any move between platforms, because templates, components and every custom feature are written again on the new stack.
• Quality checks: 10 to 20% to test functionality, formatting and performance across devices, and to walk the redirect list before launch.
• Redirect setup: 5 to 10% to map old URLs to new destinations and preserve search equity.
• Deployment and go-live: 5 to 10% for the cutover itself, the DNS switch and the checks that follow it.

Allocating funds across these phases ensures that neither technical SEO nor user experience gets neglected during the launch window.

Time is the other half of the invoice, because an agency bills the hours each phase takes and anything that stretches the schedule raises the price with it. How long each type of move actually runs is its own question, answered in our guide to how long a website migration takes.

Standard Inclusions and Custom Requirements

Knowing what a standard package includes protects your SEO migration budget from unexpected add-ons later. A proper standard migration covers scripted redirect verification, structured data migration, and thorough Core Web Vitals testing on the staging environment. It also includes 30 days of post-launch monitoring against a previous traffic baseline to confirm that performance remains stable after the switch.

That said, specific business needs can legitimately push a project beyond the initial fixed price, and the section on what makes prices rise fast lists what those are. Knowing them before signing is what turns a surprise invoice into a decision you made.

How does SEO affect migration cost?

Preserving search visibility is a major driver of website migration costs, requiring attention from day one. When a business moves domains, changes content management systems, or restructures its architecture, the impact on organic traffic is not a question of if, but how much. Getting the SEO fundamentals right from the start, particularly around URL changes, is what prevents the ranking drop that costs more than the migration did. A well-planned migration typically preserves most existing SEO equity, but achieving that requires dedicated financial resources.

Protecting organic visibility introduces specific technical requirements that directly influence the final SEO migration budget. It is usually a line item of its own, and on the shares above it is the redirect setup plus the part of the audit spent on URLs, so plan for something in the order of a tenth of the project. It scales with the number of URLs that change rather than with the size of the site, so a large estate moving to identical paths costs less to protect than a small one that restructures everything. Planners must account for several stages of optimization to ensure search engines can understand and trust the new destination.

Failing to budget for these steps often results in a careless launch where URLs change without proper forwarding and technical elements disappear. Budgeted properly, the same work is unremarkable: a content and URL audit up front, an SEO risk report, a generated 301 redirect map, the redirects managed in the CMS from day one rather than in a file somebody deletes, and Core Web Vitals verified before handover.

As of August 2026 Pagepro has delivered 20+ migrations with zero drops in Google rankings. On Localcoin’s move from WordPress to Next.js and Prismic, organic traffic has stayed at scale for more than five years after the cutover, carried largely by 2,600+ programmatic ATM-location pages, and the site passes Core Web Vitals on desktop across 1,500+ URLs and shows up in Google’s generative AI features. GP Notebook, a medical reference platform of more than 100,000 pages, replatformed to Next.js and Sanity and saw organic traffic double within two years of the relaunch.

They understood our technical goals and our desired performance metric. They were also very detail-oriented, and helped us achieve the KPIs we set for the project, including a lighter website, increased speed, and better SEO ranking.

Michael Winer, Product Manager, Localcoin

What changes when the destination is headless?

Moving to a headless stack is not the same job as moving between two template-based systems, and four of its costs have no equivalent on a like-for-like move.

• The content model is the migration. Pages stop being pages and become structured types with fields, references and validation. That modelling work happens before a single row moves, it decides what the editors can do for the next five years, and it is the phase most often left out of a like-for-like quote.
• Content moves by script, not by hand. A headless CMS is populated through its API, so the transfer is a script you write, run, fix and run again. The cost sits in the content that does not fit the pattern: bespoke layouts, embedded widgets, inline HTML from a WYSIWYG that has to become structured data.
• You can move in stages instead of all at once. Vercel documents the incremental pattern, where the new front end serves the paths that are ready and rewrites everything else to the legacy site. It costs more in setup and less in risk, and it is the difference between one launch night and a series of small ones.
• The running cost changes shape after launch. A monthly server bill becomes usage-based platform billing plus CMS seats, which is cheaper for most content sites and surprising for the ones that never measured their traffic pattern. Budget one round of tuning after launch rather than discovering it on the first invoice.

Rollback belongs in the same list. Keep the legacy stack serving until the new one is proven, lower the DNS TTL before the switch, and the rollback is one record change rather than a rebuild. That is a day of planning, and it is the cheapest insurance in the project.

What makes migration prices rise fast?

Initial estimates for a fixed-price migration often look appealing, but specific technical requirements can quickly escalate the final bill. Certain requirements drive project length and push up the total. Understanding these variables allows companies to set a more accurate SEO migration budget before development begins.

Several legitimate reasons cause a project to cost significantly more than the initial baseline estimate:

• Custom integrations and complex B2B requirements: Building bespoke third-party connections or handling multi-site consolidation expands the development workload and directly drives project length.
• Design scope and content rewrites: Undertaking significant theme work alongside the transfer requires extra design resources, and this is one of the biggest cost drivers across various platforms.
• Data quality and content volume: Moving very large content archives, launching into new markets, or extracting databases from less common platforms demands intensive mapping and cleansing processes.

Beyond direct development hours, poor planning introduces hidden financial risks. A botched transition frequently causes ranking losses and traffic drops, immediately impacting revenue. A flawed transfer can also result in higher operational costs over time, as software license fees, hosting, and ongoing maintenance grow faster than the value delivered. Project leaders can minimize immediate revenue loss by scheduling the final database switch during known low-traffic periods. On Learn Squared’s exit from Drupal 7, launch downtime stayed under four hours and revenue rose 24.35% in the first 26 days after launch, with the client’s own caveat that concurrent sales and course launches may have contributed. Anticipating these hurdles keeps the timeline intact and prevents sudden budget spikes.

How does platform choice affect cost?

The source and destination systems fundamentally dictate the technical workload and the resulting website migration pricing. Transitioning between identical systems usually presents fewer obstacles, whereas moving across completely different architectures introduces substantial hurdles. Your current tech stack directly influences the baseline estimate because extracting data from older or highly customized environments requires distinct technical strategies. The final cost depends heavily on the specific platforms involved and the level of structural compatibility between them.

The unique setup of your original site is what sets the baseline here. Certain architectural choices consistently drive higher costs because of the specialized labor required to adapt the data.

• Cross-platform transitions: Moving from WordPress to WordPress is relatively straightforward, but moving from WordPress to a headless stack such as Next.js and Sanity demands significantly more development time. The structural difference is the point of the move and also its cost: the content has to be remodelled, not copied, so developers build the mapping rather than run an importer.
• Legacy system dependencies: Migrating off a monolithic CMS or an outdated legacy system often forces engineering teams to create manual workarounds. These interventions directly inflate development hours and drive up the total cost to migrate a website.
• Custom functionality footprints: Every bespoke feature listed in the audit has to be recreated rather than exported, and the recreation carries its own testing. That is the line where a same-platform transfer stops being cheap.

These technical factors are what separate a cheap platform move from an expensive one. A same-platform transfer with stock features is close to the floor of whatever an agency charges. A move that carries custom post types, shortcodes, bespoke blocks, custom fields and a substantial plugin footprint is closer to the ceiling, because every one of those is a rebuild rather than an export. Evaluating your existing platform functionality alongside your destination goals is what turns a vague range into an estimate you can hold somebody to.

What lowers website migration cost?

Relocating digital assets often requires a substantial investment, but specific strategic choices and inherent site characteristics can actively reduce the total cost. The baseline price depends entirely on the size and complexity of the platform being moved. A smaller footprint and a simplified approach to features require less development effort and fewer compatibility checks. Controlling these variables is what keeps the SEO migration budget manageable without giving up the architecture you are moving for.

• Reduced website size: Moving a small site with a limited number of pages requires a fraction of the effort compared to an enterprise platform with thousands of URLs, and fewer URLs also means fewer redirect decisions to make by hand.
• Basic functionality retention: Keeping features simple and avoiding custom integrations reduces the need for developer intervention. Sticking to native platform capabilities avoids expensive compatibility checks and complex code translations.
• Internal task management: Handling simple administrative duties internally helps reduce professional fees. Doing tasks yourself where possible, such as executing basic content exports or performing initial quality assurance, keeps billable agency hours to a minimum.
• Fixed-price agreements: Opting for a fixed-price migration on a clearly defined, smaller scope makes spending predictable. This model works best when the site architecture is simple and the required deliverables are thoroughly documented upfront.

Cut the complexity you will not miss, not the work that protects what you have. Dropping a bespoke feature nobody uses saves hours with no consequence; dropping the redirect mapping or the audit saves a smaller number and risks the traffic the site already earns. Minimizing technical complexity remains the most reliable strategy to control the cost to migrate a website, as long as the complexity you remove is the kind that was never doing anything.

How should you budget for migration?

Setting up a realistic website migration budget requires careful planning from the very beginning. Professional migration services vary heavily in cost based on scope, complexity, and platform choice. You must begin by identifying the exact migration type to understand the financial requirements. A structured financial plan helps manage both overall expenses and the project timeline.

Initial Assessment and Asset Inventory

The first step in budgeting involves taking a full inventory of your digital assets. You need to know exactly what elements exist on the current platform before moving them. Listing everything provides a clear baseline for estimating the required labor and technical resources.

• Pages and content: Document every existing URL, text block, and media file to understand the volume of data transferring to the new system.
• Templates and design files: Count the unique page layouts and assess any specific functionality tied to the current visual interface.
• Data and integrations: Record all active user accounts, databases, and third-party software connections that need rebuilding on the new architecture.

Managing Unknowns and Project Timelines

Once the core inventory is complete, evaluate any desired enhancements and estimate the site migration timeline. Calculate how long it will take for everything to get back up and running to minimize revenue loss during downtime. To keep expenses under control, create a formal budget document and review it regularly as the project progresses. Teams can also consider a gradual migration approach to spread the financial impact over several months.

Creating a safety net for unexpected technical challenges is another step worth taking. Keep a contingency fund tied to identified unknowns rather than simply adding an arbitrary percentage to the total cost. Allocating internal staff for basic data gathering helps stretch available funds further without compromising quality. And always consult a professional agency to validate your internal calculations and secure an accurate estimate.

Approaching financial planning with methodical steps ensures the project stays within its approved limits. Proper preparation protects the bottom line while delivering the expected technical upgrades.

FAQ