Migration
Move development WordPress work into staging first.
Use staging as the receiving point for local or development backups. That way, production is not the first place where the imported site is tested.
Migration path
Import first, review second, publish last.
Site migration is treated as a staging workflow. Development work lands in staging first, then production publishing is decided separately.
Migration flow
A safer place to land development work.
- Export or prepare a backup from the development site.
- Import that backup into the staging environment.
- Check layouts, URLs, plugins, and key forms on staging.
- Run dry-run checks and confirm the intended production scope.
- Use PUSH only after the staging result is ready.
Use cases
How this page fits into real WordPress release work.
Each feature page answers the operational questions an administrator checks before production data changes.
Feature FAQ
Questions to answer before using this workflow.
Can a development backup go straight to production?
The product is positioned to import development work into staging first, then publish only after review.
Is migration into staging free?
Yes. Importing development, local, or test-site backups into staging is part of the free core.
What should I check after import?
Check URLs, forms, plugin state, layouts, media, and any content that could affect production users.
When does the paid add-on matter?
The paid add-on matters when the reviewed staging result needs to be pushed to production.
Positioning
Migration becomes easier to judge when staging comes first.
The workflow gives imported work a review step before anyone decides to update production.