A website that looks lost after migration may still have its content on the original host. It may also have transferred correctly but be loading from the wrong location, using an incomplete database, or requesting images from an old address. Before rebuilding anything, compare the source and destination as separate copies.
The first useful question is not “Which recovery tool should I run?” It is “Which part of the transfer is missing, and where does the most complete version still exist?” Keep the old environment available while you establish that answer. Do not cancel the old hosting account merely because the new homepage opens.
Record what changed during the migration
Write down the migration date, the original host, the destination host and the intended public address. Include whether the project moved to a new domain, changed from HTTP to HTTPS, moved out of a subdirectory, or retained exactly the same URLs. Those are different changes and should not be treated as one operation.
Ask the person who performed the transfer which components were copied: website files, uploads, database, configuration and any separate application data. Preserve the transfer log and the names and dates of backup files. A completion message is useful evidence of an operation; it is not proof that every page, image and record arrived.
If different people can see different versions, record the address, time and screenshot for each observation. Do not conclude that the database is gone from a browser symptom alone. The offline-versus-deleted checks help separate access problems from missing content.
Check files, database and URLs separately
For WordPress, the official migration handbook treats files and the database as separate transfer components. It also explains that changed domain or directory references can affect links and theme display. This is why a migration audit needs more than a check of the front page.
Files and media
Compare a small set of known images and downloadable files between the old and new environments. Choose an older upload, a recent upload and a file used by an important service page. Record the actual requested URL and whether the file exists at the destination.
An image visible in the editor but missing on the public page needs a different investigation from an image absent from both the media library and the transferred files. The first may involve a reference or delivery problem; the second calls for finding another source copy. Do not upload replacement images under arbitrary names before documenting the originals.
Database and content
Check recognizable content in the administration area: an older article, a recent article, an unpublished item and a known navigation label. Ask the administrator to confirm which database the destination uses and which dated export was imported. Keep passwords and connection details out of screenshots and support tickets.
A new WordPress installation with a default page does not establish that the original database was deleted. It establishes that the visible installation is not showing the expected content. The original database may remain elsewhere, or the destination may be connected to a different one.
Also establish what “export” meant. A WordPress content export contains selected content and related information; it is not a substitute for a complete copy of the installation. Ask whether the transfer used a full backup, a database export, a content export or a combination.
Public URLs and stored references
Test the original address of an important page, not just a link in the new menu. Then test one image, one article and one nested page. Record whether each address loads, redirects, returns an error or displays the wrong content.
If the project retained its domain and paths, a migration is not a reason to invent new slugs. If it intentionally changed location, the developer should review address references and the agreed redirect plan. Avoid broad manual database replacements: the WordPress migration documentation warns that naive replacements can damage serialized values. That is a specialist correction, not an emergency shortcut.
Use a missing-component record
The following record makes a handoff more useful than “the migration broke the website.” Create one row for each important failure. This is a recommended worksheet, not a report of an actual client migration.
| Record | What to enter |
|---|---|
| Original address | The exact page or asset URL before migration. |
| Expected item | Page title, image filename or function that should appear. |
| Source evidence | Whether it survives on the old host, in an export or in another copy. |
| Destination result | What the same item shows on the new environment. |
| Relevant date | Backup, export or last-known-correct date, including timezone if known. |
| Next decision | Correct a reference, transfer a missing component, review a backup or assess reconstruction. |
Do not treat matching item counts as complete validation. Two installations can contain the same number of posts but different posts. Use counts to flag discrepancies, then compare meaningful samples and the highest-value pages.
Choose the recovery path from surviving evidence
If the old installation remains usable, work from that native source first. If only a backup remains, establish its scope and date before restoring it into an isolated destination. If both environments contain useful but different changes, preserve both and agree which version owns each item before a replacement operation.
A complete destination rollback can discard changes made after migration. List newer articles, enquiries and other business records before authorizing that choice. Where transactions or private information are involved, the responsible application specialist needs to assess the data, not just the public page appearance.
If no usable native copy survives, public archives can help reconstruct captured pages. They are not a replacement for a missing application database. Our Wayback Machine restoration guide explains the public-content route and its limits. Uncaptured pages, private records and original application behavior require separate evidence and scope.
Agree acceptance checks before replacing the live site
Define success in terms that can be tested. For a content website, that may include the original page addresses, article text, navigation and essential images. A store needs a separate review of its catalogue and business data, as well as controlled functional checks. A visual match alone is not evidence that checkout or account behavior works.
- Identify the authoritative source for each missing component.
- Keep a rollback reference for the destination before further changes.
- Review the proposed correction in an isolated environment.
- Check original URLs and representative content against the source record.
- Have the owner approve unresolved differences before any live replacement.
When public content really has been lost and native recovery is unavailable, a website recovery assessment can establish what captured material is available for reconstruction. It should begin with the missing-component record, not with a promise that every part of the former application can be restored.
Frequently asked questions
Does a blank website after migration mean the database was deleted?
No. It could reflect the wrong installation, connection or imported content. Ask the administrator to verify the original and destination databases and preserve any surviving exports before changes.
Can I delete the old hosting once the new homepage loads?
Do not use the homepage alone as the acceptance test. Confirm the content, media, original addresses and required functions, and retain an independent recovery copy before closing the old account.
Can Wayback Machine recover the database that was not migrated?
Public captures can provide available page content and assets. They do not supply the original private database, credentials or transaction records. A rebuild from captures and a native database restore are different projects.
