Use case

Leave WordPress without moving DNS first

Exporting posts is the smallest part. Plugins, users, forms and cron jobs are application logic. The migration creates the project and a staging environment first. DNS comes last.

  • Bring content across as Markdown or HTML, plan permalink redirects
  • Rebuild login, forms and APIs as a backend, not as a plugin copy
  • Cut over only when staging and certificates are in place
Create a free account Why not WordPress

Start for free. No credit card required.

No one-click import Themes and plugin databases do not magically become NestJS.
Staging first The new site and API run in parallel until redirects and content check out.
DNS last The domain stays on WordPress until cutover is planned.

Pipeline for Customer App

test
build
publish
release
Every revision goes through test and release before it is public.

In short

You transfer content and the domain. You rebuild what used to be a plugin.

  • Bring along: copy, media, canonicals, redirect list, TLS, analytics IDs.
  • Rebuild: everything that was a plugin or custom PHP in WordPress.
  • Not first: production DNS. Staging first, then a planned cutover.
  • WooCommerce and heavy membership setups are their own projects, not extras.

Move with the platform or reinstall WordPress on a new host

Both are work. The difference is whether you still have a CMS without a pipeline afterwards.

Start a new project

With the Application Platform: Wizard creates repo, pipeline, homepage stack and server bootstrap

WordPress on a new host: Reinstall WordPress, restore theme and plugins

Move content

With the Application Platform: Export (XML/HTML), take into Hugo/Astro or the backend, keep redirects

WordPress on a new host: CMS export/import, permalinks often preserved

Application logic

With the Application Platform: As a backend with tests in the repository

WordPress on a new host: The same plugins, including update and compatibility risk

Secrets and access

With the Application Platform: Credentials in the platform, passed into environments

WordPress on a new host: wp-config and hosting panel set again

Parallel environment

With the Application Platform: Staging deployment on the provisioned server

WordPress on a new host: A second instance, often by hand without the same setup

Operate afterwards

With the Application Platform: Pipeline, backups, audit, optional apps in the same project

WordPress on a new host: Still updates, plugins, PHP version on the host

WordPress on a new host keeps the editor. The platform trades the editor for a repository, pipeline and server access.

As of 4 September 2026. This comparison describes typical workflows and can differ from project to project.

What you do not rebuild after cutover

The move is one-time work. The chain stays.

Pipeline instead of FTP

After the move every new revision is a push, not a plugin deploy.

Redirects in the repo

Old permalinks live as configuration, not a forgotten redirection plugin list.

Server bootstrap

SSL, proxy, backups and firewall are part of setup, not a hosting-plan checkbox.

Room for the app

When iOS or Android arrives later, it does not hang off a second service.

configurations/prod/versions.yaml 
application:
  backend_configuration:
    image_tag: 0.26.8-98
  frontend_configurations:
    customer-frontend:
      image_tag: 0.15.6-80
    admin-app:
      image_tag: 0.12.1-42
  • Customer app —
  • Admin app —
  • Backend —
What is live lives in git history – including cutover.

Migration sequence

Four steps, DNS at the end. Do not skip a step just because the domain is already bought.

  1. Inventory

    Pages, posts, media, forms, roles, cron jobs, plugins with data, third-party scripts. Write down what is content and what is logic.

  2. Project and staging

    Create the project, pick the homepage stack, connect a server. Move content, build the redirect list, point forms at the backend.

  3. Acceptance

    Links, login, mail, backups, mobile view. Leave WordPress unchanged in parallel.

  4. Cutover

    Lower TTL, point DNS at the new entry, redirect old URLs, only then turn WordPress off. Cancel hosting afterwards.

Frequently asked questions

Is there an automatic WordPress importer?

No. An XML export helps with copy. Themes, page-builder layouts and plugin tables are not taken one-to-one. That avoids landing on another CMS without tests.

What happens to my permalinks?

New paths may look different. Plan 301 redirects from the WordPress URLs before DNS changes, or you lose indexing and shared links.

Can editors keep writing in the block editor?

Not in WordPress. Copy lives in the repository or the platform homepage editor. Teams that publish dozens of articles a day should stay on a CMS or plan a separate headless setup – that is not this use case.

How long does a move take?

A brochure of a few pages is quick. Membership, shop or custom plugins make it a project, not an afternoon. The platform shortens setup, not domain logic.

Does mail delivery survive?

WordPress mail plugins go away. Transactional mail is set up in the project. SPF/DKIM DNS belongs in the same cutover as the site.

Why not WordPress When WordPress remains the right tool. Automate CI/CD What happens on every push after the move. GDPR-friendly hosting EU operations after leaving the old host. Agency client projects Move several WordPress tenants into separate projects.

Start with staging, not DNS

Create the project, move content onto a non-public environment, and plan cutover only once redirects are in place.

Register for free Talk to us

Start for free. No credit card required.