Treat migration as a small project with an inventory and an acceptance test. A content importer does not reproduce every WordPress plugin, theme or custom business process.
Inventory the real site
List published and draft content, page types, media, menus, languages, forms and the URLs that matter. Record which features come from plugins or custom code. Separate content you can import from behavior that needs replacement or a separate integration.
Agree on the supported import scope
Review the importer and release documentation for your installed version. Verify access to the WordPress REST API, authentication and supported content types. If access fails, investigate the specific restriction rather than disabling authentication or assuming the import is empty.
Test on a separate destination
Keep the original site serving visitors while you run a supported preview or test import. Compare counts by content type and status. Inspect representative long pages, Arabic and English content, images, captions and internal links. Do not equate an accepted job with a complete public-site migration.
Map URLs and rebuild required behavior
- Create a deliberate old-to-new URL map and test redirects.
- Check media delivery and files instead of assuming all remote media was copied.
- Recreate menus, forms and integrations that are within the agreed scope.
- Test permissions and publishing behavior on the destination.
Switch only after acceptance
Agree on a final content-editing window and a domain-switch plan. Confirm HTTPS, important public pages and the sign-in path on the destination. Keep a documented recovery decision and retain required backups according to your agreed migration scope.
Define success concretely
Success means the agreed records, files, languages, URLs and workflows have been checked. It does not mean every plugin was converted or that search rankings, traffic or revenue are guaranteed.