Why a finished migration still leaves exposure
Moving a WordPress site means at least two complete copies of it exist for a while: the old server and the new one, often plus a staging copy, a downloaded archive on someone's laptop and a migration plugin's backup file. Each copy contains wp-config.php with the database password and security keys, and the database itself holds user accounts, password hashes and any API keys that plugins store in options.
None of that is dangerous while you control every copy. It becomes a problem when the old hosting account lapses into someone else's hands, when a former contractor still has an SFTP login, or when a forgotten backup zip sits in a public directory. The goal of this checklist is to end the migration with exactly one live copy of each secret, and a short, known list of backups that you deliberately kept.
Do this after acceptance, not during cutover. Until DNS has settled and you have confirmed logins, payments and scheduled tasks on the new host, the old server is your rollback. Rotating credentials too early can break that rollback without you noticing.
The order that keeps your rollback intact
The sequence matters because some steps are irreversible. DigitalOcean's documentation, for example, states that destroying a Droplet permanently and irreversibly destroys it, while its automated backups are not destroyed with it and expire four weeks after creation. Other hosts differ, so read the cancellation terms of yours before you delete anything.
| Step | When | Why this position |
|---|---|---|
| 1. Confirm acceptance on the new host | Before anything else | Logins, checkout, renewals, scheduled tasks and email must work before the old copy stops being your fallback |
| 2. Take and verify a final backup of the new host | Day of cleanup | Gives you a restore point that does not depend on the old server |
| 3. Rotate payment and third-party API keys | Quiet period, after step 2 | Stripe lets old and rotated keys overlap for up to 7 days, so the new host can switch first |
| 4. Rotate WordPress security keys and the database password | Low-traffic window | Changing the keys invalidates all login cookies, so every user signs in again |
| 5. Remove SFTP, SSH and application-password access that is no longer needed | Same session | Closes paths that bypass the WordPress login |
| 6. Delete leftover backups and staging copies | After steps 3 to 5 | Any copy made before rotation still contains the old secrets |
| 7. Export what you need from the old account, then close it | Last | Invoices, logs and email may be needed later; closing is often permanent |
Rotate WordPress secrets: keys, salts, database and application passwords
wp-config.php holds eight security constants: four keys (AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY and NONCE_KEY), which the documentation calls required, and four matching salts, which it recommends. The WordPress developer documentation says you can change these at any time to invalidate all existing cookies, which means all users will have to log in again. It recommends long, random values and points to the official generator at api.wordpress.org/secret-key/1.1/salt/. On a membership site, warn learners first or do it overnight; a forced logout mid-quiz is a support ticket.
Change the database password on the new host and update DB_PASSWORD to match, so the value that travelled through the migration archive no longer works. The WordPress hardening guide also notes that the database user normally needs only data read and write privileges, and that structural privileges such as DROP, ALTER and GRANT can be revoked, while warning that updates may fail without them. On a managed host you may not control grants; on a VPS, review them when you create the new user.
Application passwords, introduced in WordPress 5.6, are credentials for scripts and apps. The core integration guide says they are managed from the Edit User screen, where you can view and revoke them, and a Last Used column helps identify ones nobody needs. They cannot be used to log in at wp-login.php, which is exactly why they are easy to forget. Revoke any created for a migration tool, and recreate the ones a live integration still needs.
- Generate new keys and salts, paste them into wp-config.php, and confirm you can log in again.
- Set a new database password, update DB_PASSWORD, and load a page to confirm the connection.
- Open Users, then each administrator's Edit User screen, and revoke unused application passwords.
- Remove administrator accounts created for a migration service or contractor.
Rotate payment and integration keys without downtime
Stripe's documentation recommends rotating keys when a team member with access leaves or changes roles, and when a key may be compromised. When you rotate a key in the Dashboard, both the old and new keys work for up to 7 days, and you choose the expiration time; choosing Now deletes the old key immediately. Stripe advises checking the old key's request logs and expiring it only after its request volume has been at zero for a few hours or days.
That overlap is what makes a clean post-migration rotation possible. Put the new key into the new host's plugin settings, watch for errors, and only then let the old key expire. If the old server is still running somewhere and suddenly starts failing payment calls, the request logs will show it, which is a useful signal that something still points at it.
Stripe also treats webhook signing secrets as separate from API keys: each webhook endpoint has its own signing secret in the Webhooks section. If you created a new endpoint during the move, delete the old one so Stripe stops sending events to a server you are about to close. The same thinking applies to email delivery services, video hosts and CRM integrations: list each one, issue a fresh key, and revoke the old one.
Close file access: SFTP, SSH and hosting logins
File access bypasses WordPress entirely, so it deserves its own pass. On WP Engine, SFTP users are created per environment under Users and SFTP, each set of credentials works for only one environment, and usernames cannot be changed after creation, so the fix for a shared or reused login is to delete it and create a new one. WP Engine also notes that SFTP credentials are separate from wp-admin and User Portal credentials, so removing someone from WordPress does not remove their file access.
The WordPress hardening guide recommends SFTP over plain FTP where the host provides it, so the password is never sent in the clear. If your old host only offered FTP, treat that password as exposed and do not reuse it anywhere. Review hosting control-panel users too: agencies and migration services are often added as collaborators and never removed.
| Access type | Where it lives | Cleanup action |
|---|---|---|
| SFTP or FTP users | Hosting panel, per site or environment | Delete migration and contractor users; recreate any shared login with a unique one |
| SSH keys | Hosting panel or server authorized keys | Remove keys for people or machines that no longer need access |
| Hosting account collaborators | Hosting account or team settings | Remove agency and migration-service users once the job is accepted |
| WordPress administrators | Users screen | Remove temporary admins; review roles for everyone else |
| Application passwords | Edit User screen | Revoke those used by migration tools |
| Payment and API keys | Each vendor dashboard | Rotate, confirm the new key works, then expire the old one |
Find and delete leftover copies
Every copy made before you rotated credentials still contains the old secrets. That includes migration plugin archives, database dumps in the web root, staging sites on the new host that were cloned from the old one, and downloads on personal machines. The WordPress hardening guide recommends removing plugins you no longer use, which applies to migration plugins once the move is done, and keeping backups in a trusted location.
Delete deliberately rather than broadly. Keep at least one verified backup of the new site, and decide whether you still need a pre-migration archive; if you do, move it to private storage you control and note where it is. On cloud hosts, check what survives deletion: on DigitalOcean, automated backups are not destroyed with the Droplet and remain until four weeks after each backup was created, and snapshots or volumes are kept unless you choose to delete them with it.
- Search the new web root for .zip, .tar.gz, .sql and .wpress files and remove any that are not intentional.
- Delete staging environments cloned before rotation, or rotate their secrets too.
- Deactivate and delete migration plugins.
- Delete local downloads of the old site, or move them to encrypted storage with a deletion date.
- On cloud hosts, list snapshots, volumes and backups attached to the old server before destroying it.
Worked example: a MemberPress site moving from shared hosting
A course creator moves a MemberPress site with Stripe from a shared host to a managed host. A freelancer handled the move using a migration plugin and an SFTP login on both hosts. Acceptance passes on a Tuesday.
Wednesday: take a backup on the new host and download it. Rotate the Stripe secret key with a 3-day expiry, paste the new key into MemberPress, run a test purchase and confirm the webhook arrives. Thursday at 11pm local time: generate new security keys, rotate the database password and confirm login. Remove the freelancer's SFTP users on both hosts, delete their WordPress admin account and revoke the migration plugin's application password. Friday: delete the migration archive from the new web root and the plugin itself. Saturday, after the old Stripe key shows no traffic: let it expire, export invoices from the old host and cancel.
Nothing in this sequence requires downtime. The only user-visible effect is one forced login, scheduled for the quietest hour.
Questions before you decide
Will changing the WordPress security keys log everyone out?
Yes. The WordPress developer documentation says changing the keys invalidates all existing cookies, so all users have to log in again. On a membership site, schedule it for a quiet hour and tell learners in advance.
How long can an old Stripe key keep working after rotation?
When you rotate a key in the Stripe Dashboard, both the old and new keys work for up to 7 days, and you can choose a shorter expiry or Now. Stripe advises expiring the old key once its request logs show no traffic.
Does deleting a DigitalOcean Droplet delete its backups?
No. DigitalOcean says destroying a Droplet does not destroy its automated backups, which expire four weeks after creation, and that snapshots and volumes are kept unless you choose to delete them. Check other hosts' terms before cancelling.
Do I need to revoke application passwords after a migration?
Revoke any created for migration or one-off tools. They are managed from the Edit User screen, cannot be used to log in at wp-login.php, and have a Last Used column that helps spot ones no integration still needs.
Sources & verification
Product details and prices can change. Check the linked provider before buying.
- WordPress Developer Resources: Editing wp-config.php Accessed 30 Oct 2026
- WordPress Developer Resources: Hardening WordPress Accessed 30 Oct 2026
- Make WordPress Core: Application Passwords integration guide Accessed 30 Oct 2026
- Stripe Docs: API keys Accessed 30 Oct 2026
- WP Engine Support: SFTP Accessed 30 Oct 2026
- DigitalOcean Docs: How to destroy Droplets Accessed 30 Oct 2026
Sources link directly to providers. Product buttons may use separately labeled affiliate links. Read our disclosure.