Skip to main content

Migration workflow

The wizard runs the move in logical phases (e.g. styles, templates, then content/media in batches). Exact step names and UI can vary by plugin version, but the idea is:

Typical end-to-end flow​

  1. Install the plugin on both sites and activate it.
  2. On the Etch target, prepare a flow that identifies the target (commonly a migration key / pairing—labels depend on the UI).
  3. On the Bricks source, enter the key and keep verifying until the wizard confirms the pair is valid.
  4. Discovery / analysis runs. On very large sites, some UI surfaces load in stages so the full admin is not locked up for a single huge request.
  5. Select & map: choose what to migrate—post types, templates, optional packages, exclusions, and related plugin context where shown.
  6. Options: project-specific choices (e.g. template shell / header–footer, optional premigration schema, if offered).
  7. Start the migration and follow progress in the UI. When something fails, the product generally supports retrying failed parts without always restarting from zero—subject to your host limits.

Online vs. file (ZIP) import​

  • Online: source and target talk to each other for the whole run.
  • Offline (ZIP): you move packaged exports; see Offline (ZIP) import.

Afterward: QA on Etch​

Plan time for review on the target: templates, representative content, media, fonts, and dynamic data—especially for complex Bricks builds. See Limits & expectations.