CodePoint Server-to-Server Migration

1. 01Install and activate the plugin on BOTH sites.
2. 02On the old site: Tools → CodePoint Migration → “I’m on the OLD site” → copy the connection key. Optionally list folders to skip.
3. 03On the new site: “I’m on the NEW site” → paste the key → Connect. Review the comparison and any warnings.
4. 04Start migration. You may pause, close the tab, and resume at any point.
5. 05Finalize. If “Keep my login” is checked (default), you usually stay signed in; otherwise log in with the OLD site’s username and password.
6. 06After your domain points to the new site, use the “Change domain name” tab to replace the temporary address with the final domain, then go to Settings → Permalinks and click Save Changes.
7. 07Deactivate and delete the plugin on both sites. Drop the rollback tables (your table prefix followed by cps2s_old_, e.g. wp_cps2s_old_options) once the site is confirmed healthy.

When do I change DNS, and does the plugin do it?

DNS changes happen at your domain registrar or hosting/DNS provider — no plugin can do them for you. Ask them to point your domain at the new website (the Change domain name tab shows this server’s address if available), make sure a secure certificate (HTTPS / SSL) for the domain is installed on the new server, wait until the change has taken effect while the old site keeps serving visitors, and only then run the domain update. The button checks whether the domain currently points here and warns — without blocking — if it does not yet.

Why am I logged out after finalizing?

Finalizing switches in the old site’s database, including its users. If your login could not be kept (same username already exists on the old site, or you unticked “Keep my login”), you need to sign in with the old site’s admin username and password. That is normal.

The connection fails with HTTP 404

The old site’s REST API is not reachable at /wp-json/. Enable pretty permalinks on the old site (Settings → Permalinks → anything except Plain) and confirm the plugin is active there.

The connection fails with HTTP 403

The key is wrong, expired (72-hour lifetime), or was invalidated by a completed migration. Copy a fresh key from the old site. After 10 failed attempts the old site locks the requesting server out for 15 minutes.

Can I run a second migration to the same site?

Yes. Connect again with a fresh key. Before files are copied, other plugins on the new site are temporarily turned off (and a default theme is used) so overwriting plugins like Rank Math cannot crash the migration mid-run. Before the new database is installed, the plugin also frees space from the previous previous rollback backup. Press Start over first if a previous attempt left the site mid-migration.

What happens to plugins or themes that were only on the new site?

They are not restored. Migrating makes this site match the OLD site’s plugins, theme, and active-plugin list — it is a replacement, not a merge. If “Clean up leftovers” is checked (the default), anything this site had that the old site didn’t is deleted during the copy. If you uncheck it, those files are left on disk but end up inactive, since the imported database’s active-plugin list only knows about the old site’s plugins. Either way, reinstall or reactivate anything you want to keep that wasn’t on the old site.

Does this preserve database foreign key constraints?

No, by design. A small number of tables (some of WooCommerce’s newer order-related tables are the confirmed case) use real foreign key constraints between tables, in addition to the relationships WordPress and its plugins already manage in PHP. Recreating those constraints exactly would require staging every table in dependency order instead of one at a time, and every row of data on both sides of the relationship is copied in full regardless — so the constraint itself is dropped during the copy rather than recreated. The data, and the relationships that data represents, are unaffected.

Can I roll back after finalizing?

Yes — your previous tables are preserved with an cps2s_old_ prefix inserted after your own table prefix (so wp_options is kept as wp_cps2s_old_options). Renaming them back (via phpMyAdmin or WP-CLI) restores the pre-migration database. Files are not backed up automatically; transferred files overwrite in place.

The prefix includes your site’s own table prefix so that installs sharing a database cannot overwrite each other’s rollback copies.

Does it work behind Cloudflare or Wordfence?

Usually, but aggressive rate limiting can interrupt the chunked transfer. If you see repeated failures, allowlist the new server’s IP address on the old site for the duration of the migration.

Does it migrate multisite?

No. Single-site to single-site only.