To move a WordPress site to Praxis, arrange the migration with Amadalis. Use Migration > Migration jobs in the site admin to review the move, compare pages and inspect what still needs work.
Checked against the product’s code on 7 November 2026.
The product can turn supported WordPress content into native Praxis content that your team can edit. What the source makes available and what your site uses determine the scope.
For an agency, choose the client’s intended owner at the start and manage access through the agency workflow.
The public migration preview is by invitation. Treat a preview as an assessment, rather than a completed move or approval to switch off the original site.
Start with the site you have
Section titled “Start with the site you have”- Share the source site’s address with Amadalis.
- List the things it must keep doing. Include its page builder, forms, shop, member content, languages, integrations and important old addresses.
The migration can read a WordPress export file, an authorized connection or the Praxis exporter. Those sources expose different parts of the site. A public scan alone cannot reach private content, plugin tables or all theme settings.
Agree the source connection through the migration controls with the team. Keep WordPress credentials out of copilot conversations.
What can move
Section titled “What can move”Coverage is checked for the actual site. This table describes supported destinations, not a promise that every source setting converts.
| Source material | Destination or review |
|---|---|
| Pages and posts | Native content, initially in drafts. Page structure and old addresses are reviewed. |
| Elementor and WordPress block editor layouts | Native sections and elements for supported constructs. Widgets, layout and responsive behavior need comparison with the original. |
| Other builders and unusual blocks | Scope them separately. A detected builder is not proof that its whole design can be reproduced. |
| Categories, tags, menus and authors | Native groupings, navigation and author records where the source supplies them. |
| Custom post types | A collection mapping agreed during review. |
| Advanced Custom Fields (ACF) or Secure Custom Fields (SCF) | Native fields with the matching value type, where supported. Structured values and relationships need review. |
| Images and files | Downloaded files with integrity checks and a result for failures. |
| SEO data | Native titles, descriptions, preferred page addresses, robots settings and social fields from supported SEO records. |
| Forms | Supported definitions become native forms. Unsupported fields and behaviors are named for review. |
| WooCommerce | Supported catalog and commerce records move into native tables. Checkout, payment setup and the store’s behavior need a separate review. |
| Other plugin data | A native destination where supported, or a named inventory and review item. Storing a record does not recreate the plugin’s behavior. |
What happens to media files during a WordPress migration
Section titled “What happens to media files during a WordPress migration”Supported WordPress media files are downloaded and checked, then stored or matched to an existing file. Failures are recorded by source address and reason. Review those results and keep the original site available while you compare the imported pages.
WordPress plugin software does not run as part of the migrated site. Confirm each behavior you depend on in Praxis.
How the service is reviewed
Section titled “How the service is reviewed”- Assess coverage. Review what the chosen source can provide and what is missing.
- Import and inspect. Review the imported items and the named findings in Migration.
- Compare pages. Use Compare ⇆ in Migration to see the original and the native page side by side at a desktop width. Check phone layouts, menus, pictures and forms on the pages themselves.
- Resolve exceptions. Decide how to handle unsupported behavior and items that need manual work. Read the Honesty report, which lists gaps and work needing review.
- Approve the switch. Review the Cutover evidence for switching from the old site.
- Publish approved content.
- Arrange the domain change separately.
Imported pages and posts start as drafts. An import can still change the live site: redirects can start forwarding, a menu with the same name can be replaced and the imported theme can become active. Agree the destination and timing before importing into a site that already serves visitors.
Job controls in Migration can roll back the drafts an import created. Agree with the team how redirects, the menu and the theme would be restored before importing into a live site.
Items that need a separate plan
Section titled “Items that need a separate plan”Products brought in by the import are read only in Products for now.
- Past form entries and advanced form behavior such as uploads, conditional logic, payment fields and captchas.
- Store checkout, setup of the payment provider and any recurring billing that the business depends on.
- Customer access and claims. WordPress passwords and sessions are withheld, and payment credentials are not activated by the import.
- Languages beyond the host’s current English and Spanish configuration.
- Features provided by a plugin whose data is preserved without a working native replacement.
These are scope questions to settle before cutover. A completed import does not settle them by itself.
Keep the original available until review is complete
Section titled “Keep the original available until review is complete”The product reports unresolved dependencies and whether it can verify that the source is no longer required. Review that result with the team. Keep the original site and its backups available until the pages, redirects, files and business functions have been accepted.
Confirm commercial scope directly with Amadalis.