Backup and disaster recovery for WordPress after an AI migration
An IT expert's practical guide to backups, restore tests and recovery plans for a WordPress site converted from an AI builder.
Convert2WP – convert your AI website to WordPressClick here
Why backups become your job
On an AI platform, backups are often handled silently by the provider, and many users never think about them. After moving to WordPress you own the site, and with ownership comes responsibility. I have been called by clients whose site was broken by a faulty update or a hacked plugin, and the first question is always the same: when was the last backup, and does it work?
A good backup strategy is cheap, simple and invisible until the day you need it. On that day it is worth more than any plugin or design.
What must be backed up
A WordPress site consists of two parts: files and database. Files include the theme, plugins and uploaded media. The database contains pages, posts, settings, users and orders. Both must be backed up together, from the same moment, otherwise a restore can leave images missing or settings mismatched.
I also store a copy of configuration that lives outside WordPress, such as server rules, DNS records and the list of plugins with licence keys. These details are easy to forget and hard to reconstruct under pressure.
The three-two-one rule
I follow a simple rule: keep three copies of your data, on two different types of storage, with one copy off-site. In practice that means the host's daily backups, plus an automatic backup to separate cloud storage that the host cannot touch. If the host has a serious problem, the off-site copy is still safe.
Retention matters as well. I keep daily backups for at least two weeks and weekly backups for a few months. Some problems, such as a hidden malware infection, are discovered only after days.
Testing restores
A backup that has never been restored is a hope, not a plan. Every few months I restore a recent backup to a staging environment and check that the site works: pages load, images appear, forms submit, logins work. This test regularly reveals small issues, such as an excluded folder or an expired storage credential, long before they matter.
The test also tells you how long a restore takes, which is essential information for planning.
Writing a recovery plan
I write a one-page recovery plan for each client. It lists who to call, where backups are stored, how to restore them, how to put the site in maintenance mode and how to inform customers. It includes the expected recovery time and the maximum acceptable data loss, for example the orders of one day.
In a stressful moment nobody wants to think. A short, clear plan turns panic into a checklist.
Common causes of incidents
Most incidents I see are not dramatic attacks. They are updates that conflict, a plugin with a bug, an editor deleting the wrong page, or an expired domain. Staging and automatic backups before updates prevent most of them. Two-factor authentication and limited administrator accounts prevent many security incidents.
Small problems after a migration are normal and easy to fix. Backups are what make sure that a bigger problem stays a small one.
A routine that keeps you safe
My recommended routine: daily automatic backups, a backup before every update, monthly review of backup logs, a restore test every quarter and an annual review of the recovery plan. It takes very little time and gives peace of mind.
Owning your website is one of the best reasons to move from an AI builder to WordPress. Protecting it with proper backups is how you make that ownership safe.