How long does it take to do a website migration?

A website migration can take a few days or several months, depending on what you are moving. Changing hosting is the quickest job, usually 1 to 5 days. Moving to a new CMS or domain takes 2 to 12 weeks, and replacing the whole platform takes 3 to 9 months. Below we break down what happens in each phase, what slows it down, and how to plan the launch so you do not lose traffic.

How long does each type of migration take?

The type of move sets the order of magnitude before anything else does. These bands are planning assumptions, not measurements: use them to size the project, then replace them with your own numbers once the audit is done.

Basic Hosting Transfers

Moving a site to a new server without changing its core structure is the fastest job on the list. What stretches it is rarely the copy: it is the DNS wait, which you control with the TTL, and any custom server configuration that has to be recreated on the new host.

Small to Medium Business Sites

A CMS or domain change is the common case for a small or medium business site. Where you land inside that range is decided by how many URLs change and how many of them map one to one; the pages that merged or disappeared are the ones that cost days.

Platform Overhauls and Enterprise Sites

Changing the underlying technology or moving a large database extends the timeline into months. The long pole is rarely the content: it is rebuilding custom functionality and rolling the change out gradually, and the largest content estates sit at the top of that range.

What affects website migration duration?

Every digital transfer is different, so migration timelines vary based on specific technical factors. Each planning phase tends to surface new challenges that shape the schedule. Your main goal during this period is to figure out exactly what’s needed to protect your traffic before, during, and after launch. A few core variables ultimately determine whether the process takes days or months.

Size and Architectural Complexity

Domain size is one of the biggest factors affecting both cost and timeline. A small site is much faster to migrate than one with hundreds of pages. Several structural elements can heavily influence how long the work takes:

Evaluating these structural components early prevents unexpected delays later on.

Hosting Infrastructure and Planning Requirements

Beyond the site itself, the environment it moves to plays a role in timing, though transfer speed is rarely the bottleneck. Configuration is. Custom server setups, security rules and integrations on the old host do not move automatically, so each one has to be rebuilt and tested on the new platform. Listing them during the audit keeps them from surfacing a week before launch.

Migrating to a Managed Platform

On a managed platform such as Vercel, most of that infrastructure is configuration rather than setup, and the switch itself is documented. Vercel’s zero-downtime process has you add the domain and let the certificate be issued before touching DNS, and keep your current DNS provider until the new site is verified. Pointing the domain over then means changing an A or CNAME record, which usually propagates in about five minutes, while moving the whole DNS zone to Vercel’s nameservers is optional and can take up to 48 hours.

The redirect list has its own limit worth knowing before launch day: configuration redirects are capped at 1024 routes per deployment, so a large migration loads them as bulk redirects from a CSV, JSON or JSONL file instead. Custom server rules from the old host, such as authentication or geo-routing, still have to be rebuilt either way.

How can you shorten a website migration timeline?

Most of the time a migration loses goes to waiting rather than to building. Four decisions shorten it:

• Agree a content freeze date early: pages published during the project have to be migrated twice, and the second pass always lands in the busiest week.
• Script the content migration: a script can be rerun after every fix, which is what makes a second or third pass cheap instead of another week of copying.
• Run the old and new sites in parallel: launch day becomes a DNS switch rather than a rebuild, and the rollback is one record away.
• Migrate section by section: Vercel recommends an incremental migration, where the new site serves the paths that are ready and rewrites everything else to the legacy site, so both run at once and no section waits for the last one.

Pagepro packages that approach as Nexity, its migration setup for Next.js and Sanity on Vercel. The offer is a deployable foundation in four weeks, with the content and URL audit, the 301 redirect map and the SEO risk assessment inside that scope rather than quoted separately afterwards.

What is the pre-migration audit?

A pre-migration audit is the diagnostic foundation for the entire project. This evaluation happens before any files or databases move to a new server. The goal is to determine what from the current setup is usable and to catch technical issues before changing domains. Running this check prevents major data loss and gives you a clear baseline for the future configuration.

Content and Performance Evaluation

Reviewing existing site data ensures you only transfer what’s actually worth keeping. The process starts by identifying content that must be included in the migration. Pre-migration audits help uncover discrepancies, redundancies, or outdated data that would otherwise clutter the new platform. Categorizing these assets early makes the rest of the process considerably smoother.

• Top performing pages: Compiling a list of high-traffic URLs and their conversion rates protects your most profitable pages from unexpected ranking drops.
• Data discrepancies: Spotting broken links or missing meta tags early prevents carrying existing structural errors into the new system.
• Obsolete content: Flagging outdated articles or retired landing pages lets you intentionally exclude them from the final transfer.

Technical Crawling and URL Inventory

Capturing the exact structural state of the current domain is a mandatory step. Before touching anything, your SEO lead runs a full crawl of the existing site using tools like Screaming Frog or Sitebulb. Extracting a complete sitemap ensures no pages are missed during the URL mapping phase.

This initial snapshot also provides the metrics needed for later verification. Once the launch is done, a post-migration audit will compare the live site against this baseline to confirm everything works as intended.

What sets the audit’s duration is not the crawl, which runs unattended, but the decisions that follow it: which pages to keep, which to merge, which to retire, and who signs that off. A site with a handful of templates and one owner clears that in days. One with many sections and several owners spends more time waiting for answers than crawling, which is why the audit is the phase most often underestimated.

How long does migration testing take?

Testing typically requires one to three weeks, depending on how complex the site architecture is. It starts once the new site runs on a staging environment that mirrors production, with the same content, redirects and integrations. On Vercel, every branch gets its own preview deployment, so the team can test on a real URL without a separate staging server. You should never run a migration directly on the live site. Testing in a safe environment lets developers and QA find broken elements while the SEO lead refines the redirect strategy. This is also the point where the overall timeline stops being a guess.

Validating Server-Side Redirects

A big part of the testing window involves verifying your URL mapping. Developers implement server-side 301 redirects for every identified page, and QA tests the full list before launch. Confirming that these new paths work correctly is a mandatory pre-migration check. Teams evaluate these connections on the staging server to make sure traffic routes properly. Checking links thoroughly before going live protects search engine rankings and reduces the risk of future 404 errors.

Simulating the Final Launch

The testing phase wraps up with a mock deployment on the staging setup. This trial run ensures the actual migration can be launched with minimal downtime. QA reviews the test environment to confirm that internal links, analytics tracking, and third-party integrations all work correctly. Finishing this step means everything is ready for the official release and gives the team a clear picture of what to watch for after launch.

How do 301 redirects affect timing?

Building a solid 301 redirect strategy takes up a significant portion of the overall project schedule. Teams need to map every existing URL to its exact replacement to preserve organic search traffic. Poor routing decisions hurt SEO and extend the timeline as developers scramble to fix broken links. Getting the URL matching right from the start is essential for maintaining search rankings during the transition.

Creating the Mapping File

Constructing the redirect map takes time and close attention to detail. The SEO lead and the content owners match legacy pages to their new equivalents, and developers automate the rule-based matches with scripts. Done correctly, this process transfers most of the ranking value from old URLs to the updated domain. Rushing through the mapping stage often results in traffic drops, which is why careful execution matters so much.

The time goes into two piles, and only one of them scales with the size of the site. URLs that follow a pattern, a blog path, a category prefix, a language folder, are matched with a rule, and thousands of them cost minutes. The rest, the pages that merged, split, or disappeared, are decided one at a time, and that pile is what sets the schedule. Count it during the audit rather than discovering it during the build.

Plan for the redirects to outlive the project. Google asks site owners to keep them as long as possible, generally at least a year, so the rules belong in the new platform’s configuration rather than in a temporary file somebody removes after launch.

Avoiding Temporary Redirect Errors

Choosing the right server response code determines how search algorithms process the architectural change. Always implement permanent 301 redirects rather than temporary 302 protocols. Google’s redirect documentation is specific about the difference: a permanent redirect is a signal that the target should be canonical, so the new URL is the one that appears in search, while after a temporary redirect Google keeps showing the old URL. Getting this right takes time upfront, but it prevents ranking drops after going live.

What can go wrong during migration?

Even with thorough planning, moving a digital property from one environment to another carries real risks. Transferring large volumes of files and updating database structures creates opportunities for technical failures that can affect both user experience and search visibility. Understanding these potential problems is the first step toward preventing them.

Data Loss and Corruption

One of the biggest risks during any transition is data integrity. If the migration isn’t executed correctly, content can go missing from the new server entirely. Automated migration tools add their own hazards, including database corruption or incomplete transfers if the software is misconfigured. To avoid these failures, teams must always secure full backups, test thoroughly in a staging environment, and verify all data after the transfer.

Availability and Technical Errors

The cutover process frequently exposes sites to temporary instability. Downtime can prevent visitors from accessing your services, and structural changes often generate crawl errors, missing pages, or broken links during the transition. A flawed 301 redirect strategy makes things worse, since broken links and incorrect redirects damage SEO rankings by disrupting the paths search engines use to navigate the site.

Implementing a Rollback Strategy

Because failures are always possible, every project needs a safety net. A defined rollback plan lets you revert to the previous version of the site with minimal disruption if serious issues appear after launch. Being able to roll back quickly protects revenue and reputation while developers investigate the root cause in a secure staging environment.

Anticipating these problems keeps the team prepared for worst-case scenarios and protects the site’s assets throughout the transition.

When should a website migration launch?

Picking the right moment to deploy requires balancing visitor impact with team availability. The cutover needs to happen as quickly as possible to minimize downtime and protect organic traffic. Scheduling it during low-traffic periods, like late at night, means fewer users run into disruptions while the servers switch over.

You also need a launch date when internal coordination is straightforward. Many project managers lean toward weekends because of lower user activity, but a weekday is often the safer choice. Deploying on a Tuesday or Wednesday night gives you immediate access to your full development team if something goes wrong. DNS update timing also matters during this window, since name server propagation determines when visitors actually reach the new destination.

Pagepro measured that window on the Learn Squared cutover, moving an e-learning platform off a legacy CMS: Launch downtime under 4 hours (measured at cutover).

That wait is set by the TTL on your DNS records rather than by the migration itself. AWS puts the typical TTL of an NS record at 172,800 seconds, two days, and its migration procedure is to lower that value to between 60 and 900 seconds first, then wait for the old TTL to expire so resolvers pick up the change together. Skip that step and a mistake can leave the domain unreachable for up to two days; take it, and the switch itself is measured in minutes.

Once the new environment goes live, several technical tasks need to happen right away to help search engines catch up:

• Submitting the XML sitemap: Regenerate this file from the new system and upload it to Google Search Console immediately so new URLs get indexed quickly.
• Removing legacy sitemaps: Delete outdated map files from search engine portals to prevent crawler confusion about old page locations.
• Updating robots directives: Generate and submit a fresh robots.txt file at launch to guide search bots through the updated site architecture.

Completing these steps at deployment helps maintain indexation momentum and builds a clear connection between the old and new versions of the site.

What happens after website migration?

Once the cutover finishes, project focus shifts to post-launch monitoring. The initial deployment concludes the build phase, but tracking how search platforms and visitors interact with the updated architecture remains important. If the transition was planned and executed well, the immediate impact on rankings and organic traffic should be minimal. That said, teams still need to actively look for hidden technical issues in the weeks following launch.

Your technical team should prioritize several key verification tasks:

• Crawling for technical errors: Run a full site crawl on the live environment to uncover broken links or missing assets, and fix them before search engines register the problems.
• Tracking keyword rankings: Monitor core search positions daily to understand how the new pages perform and catch any unexpected visibility drops early.
• Evaluating indexation health: Check Google Search Console regularly for crawl errors and indexing statuses, confirming that search bots process the migrated content without issues.
• Assessing the backlink profile: Verify that external links point to functional pages and that existing redirect rules successfully pass authority to the new URLs.

Even with careful monitoring, search engines need time to evaluate the updated architecture, so some recovery period is expected.

Staying on top of these checks during the first few weeks lets teams fix traffic drops quickly. Adjusting configurations based on live performance data helps ensure the transition ultimately strengthens the site’s position.

How long is SEO recovery after migration?

Most site owners see a noticeable dip in search rankings right after launch, followed by a gradual recovery. This is normal post-migration volatility, occurring while search engines recrawl the updated architecture and process new index signals. Google’s site move guidance tells site owners to expect temporary fluctuation during a move, and says that for a medium-sized site it can take a few weeks or more before Google shows the new URLs instead of the old ones, longer for larger sites. How fast it settles depends on the number of URLs and how quickly your server responds.

Planning Windows to Work With

Recovery is a window to plan for rather than a date to promise. Budget 3 to 6 months of watching and fixing for a platform move with URL changes, and treat a well-executed domain migration with correct redirects as the faster end, often visible within 1 to 3 months. On a large site, plan at least three months for the SEO work itself, covering staging, quality assurance, and implementation, separately from the recovery window that follows launch.

Factors Extending the Timeline

Larger sites or migrations with significant structural changes take longer, sometimes 9 to 12 months before the picture is fully stable. Managing a large volume of inbound links that now pass through redirects is one specific factor that lengthens recovery, since search algorithms need extra time to evaluate and pass equity through modified paths. Despite these delays, a properly executed migration leads to a solid recovery with consistent SEO signals over the medium term. Ongoing post-launch monitoring helps keep the site on track toward full search visibility.

What technical checks should continue?

Finishing a migration doesn’t mean the technical work stops. Continuous post-launch monitoring is essential to ensure the new platform holds up structurally as fresh content gets added. Regular audits prevent performance regression and protect the gains made during the transition.

Core Web Vitals and Performance Metrics

Google states plainly that Core Web Vitals are used by its ranking systems, so ongoing performance measurement is a real priority. Teams need to consistently track page loading speeds alongside metrics like Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS).

Pagepro saw that pay off after replatforming GP Notebook, the medical reference platform used by UK GPs: The replatformed site passes Core Web Vitals on mobile, the legacy site never could (CrUX).

Keeping scores high requires continuous work: compressing images, implementing lazy loading, and testing mobile responsiveness on newly published pages. Measure the field data rather than a lab score alone, because that is what the ranking systems read.

Security and Accessibility Standards

Routine checks also need to cover security and usability. On managed platforms such as Vercel, SSL certificates are issued and renewed automatically, but any domain or subdomain left on the old host still needs its certificate checked before it expires and throws a browser warning. Accessibility checks shouldn’t stop once staging tests are done, either. As new articles, templates, and components go live, editors and developers need to keep running these checks on an ongoing basis.

Building these evaluations into standard operating procedures prevents technical debt from piling up and keeps the migration investment protected well into the future.

If seeing your own content on a new stack would answer the timeline question faster than another estimate, Pagepro makes the standing offer it published with its four-week Darktools rebuild: “I will rebuild part of your website with your real content in 48 hours. No cost, no commitment.”

FAQ