How Long Does a WordPress to Next.js Migration Take? The Phases and What Stretches Them

The calendar is set by decisions, not by typing

Owners tend to picture a migration as a developer copying pages, so they estimate it the way they would estimate copying pages. That part is real, but it is rarely what decides the date. A migration is a chain of small approvals: this page structure, this design, these redirects, this launch day. Each link waits on a person. When those people answer within a day or two, the project moves at the speed of the work. When they answer in two weeks, it moves at the speed of their inbox.

So this page does not promise a number of weeks. Anyone who quotes a firm duration before seeing your site is guessing. What we can do is show you every phase, what happens in it, and the specific things that make it longer or shorter, so you can estimate your own project with your eyes open. You get an actual schedule with the fixed quote after the free audit. One choice changes the whole calendar: a straight port keeps the current design, while a Next.js rebuild adds design and content work up front and runs longer for it.

Seven phases, each with its own accelerator and brake

Notice how many of the brakes in the right-hand column are about access and approvals rather than engineering. That is good news: they are the ones you control. The engineering brakes (builder content, stores, integrations) are known after the audit and priced into both the quote and the schedule. The cost guide covers how those same drivers move the price.

The phases also overlap more than the table suggests. Content extraction can start the day the structure is approved, long before the design is final, because pulling words and images out of WordPress does not depend on how they will look. Templates are built while the content is being cleaned. Redirect testing begins as soon as the first page types exist on the preview address. A project that ran strictly one phase after another would take noticeably longer than one where the work is staggered, which is why the schedule you receive shows parallel tracks rather than a single line. The one phase that cannot overlap is launch: it waits until testing is finished, every time.

Your homework, and when we need it

Most delays are a missing item, found late. Gather these early and the project loses most of its waiting. None of it is technical; it is the paperwork of owning a website.

• Admin access to WordPress and hosting, so we can export content, media and plugin settings. A staging copy is welcome but not required.
• Domain registrar or DNS login, confirmed working before launch week. This is the single most common launch-day surprise.
• Google Search Console and analytics access, so we can see which URLs earn traffic and protect them first.
• Brand files: logo in vector format, colors and fonts, plus any photography you own the rights to.
• Form and notification recipients: who gets each form, and what each confirmation email should say.
• Third-party accounts: CRM, booking, payment and email marketing logins or API keys, along with permission to test against them.
• One decision-maker, named, who can approve structure and design without convening a committee.

Two approval points matter more than the rest: the page structure with its URL map, and the design. Everything after them is built on top. Changing either late is the most reliable way to add weeks, which is why we ask for them in writing.

Small, medium, builder-heavy, store: how the shapes differ

We will not print week counts for these, because the drivers above swing them too much. What we can say is how the shape of the project changes with the kind of site you have. Find yours and read the driver that dominates it.

Theme matters less than you might think. A site on a lean theme such as GeneratePress or Kadence usually has cleaner content, while themes that ship their own builder, such as Avada, tend to lengthen the content phase.

The third option

Athena CMS, with AI agents on staff.

Not a theme and not a blank Next.js repo. The content system we put behind every custom site: plain fields, a real preview, every version kept, and AI agents that handle the chores a plugin only nags you about.

• PPicassoImages
• AApolloSite analysis
• AAresCompetitor watch
• PPrometheusContent holes
• AAtlasPage depth and structure
• DDelphiAI search visibility

ZDAOAand 12 more agents. Two come with Athena; the rest are monthly add-ons.

Meet the agentsTake the Athena tour

PPicassoWeekly · ImagesAApolloWeekly · Site analysis

Your old site keeps working until the minute it is replaced

Nothing about a migration requires taking your site down. The new site is built on a private preview address while the WordPress site keeps taking calls, orders and form submissions. You review real pages there, not screenshots. Search engines are kept off the preview so it never competes with the live site.

Near the end comes a short content freeze: a window in which nobody publishes on WordPress, so the final content export matches what visitors see. For most sites the freeze is a few days. Anything that cannot wait, such as an urgent price change, gets made in both places. Then comes cutover.

1. 1

   Lower the DNS TTL

   A day or more before launch, the DNS records get a short time-to-live, so the switch spreads quickly instead of lingering in caches.

2. 2

   Final export and redirect test

   The last content changes are pulled across, and every old URL is tested against the redirect map. The method is in WordPress to Next.js redirects.

3. 3

   Switch DNS

   The domain points at the new site. Visitors start arriving within minutes as caches expire.

4. 4

   Smoke test live

   Forms submit, emails arrive, payments run, analytics records, the sitemap loads and no page is blocked from search.

5. 5

   Keep WordPress parked

   The old install stays on its server, unpublished, for a while after launch. If anything was missed, the content is still there to fetch.

Email is one detail worth a sentence. If your mail runs through the same DNS zone, the records for it are copied exactly before the switch, so moving the website does not move or break your inbox.

What quietly adds weeks

These are the delays we see most, roughly in order of how often they happen. Most can be prevented with a short conversation during the audit.

• A redesign request arriving after the design was approved, which reopens the build for every page type that changed.
• A plugin that turns out to do something important nobody mentioned, such as syncing leads to a CRM or generating PDFs.
• Content edits on the old site during the freeze, which then have to be found and copied by hand.
• A vendor slow to issue API keys or a test environment for booking, payments or inventory.
• Legal or compliance review of pages that were never reviewed before, discovered because someone finally read them.
• Approvals routed through several people with different opinions about the homepage.

Very little on that list is solved by working faster. It is solved by deciding faster. If you know your organization approves things slowly, tell us at the start and we will build the schedule around it rather than pretend otherwise.

The weeks after launch belong to the timeline too

Launch day is not the end. Search engines need time to recrawl the site and follow the redirects, and Google says plainly that rankings can fluctuate during a move and settle down over time. The work in that window is watching: Search Console's page indexing report, 404s, form deliveries and traffic to the pages that mattered most before the move. The checklist for that period is in migrating without losing SEO.

Redirects stay in place long after that. Google's guidance is to keep them as long as possible, generally at least a year, and we treat them as permanent. Meanwhile your team is already editing in Athena CMS, where Argus watches for broken links, failing forms and slow pages, and Iris keeps search titles and descriptions in order. More on what changes for your team is at switching from WordPress, and the platform comparison behind the move is WordPress vs Next.js.