# Migrate an Existing Website

Recreate an existing agency website in Workganic while preserving approved content, search details, links, forms, and a safe rollback path.

Reviewed 2026-09-02

## Define the migration

Confirm that the agency controls the existing site, its content, media, and domain. Record the date the source site was reviewed and identify who will approve the recreated site. Do not copy content or media that the agency does not have permission to reuse.

The goal is functional and visual parity using Workganic-native blocks. A migration should preserve the approved message, page structure, brand, useful search details, links, and form intent without carrying over hidden code or unsupported extensions.

## Inventory the source site

Create a page map with one row for every public path. For each page, record:

- Page title and public path.
- Purpose and primary action.
- Section order and approved text.
- Images, logos, downloadable files, and ownership status.
- Internal and external links.
- Form fields, required consent, confirmation, and intended destination.
- Search title, search description, and whether the page should be indexed.
- Mobile behavior and any interactive element that must be recreated.

Also record redirect needs for any path that will change. Do not collect passwords, private submissions, visitor records, or hidden site configuration in the inventory.

## Prepare a WordPress source site

For a WordPress migration, use the public site as the source of truth for what visitors can see. Review the page list, navigation menus, reusable header and footer content, approved media, forms, search details, and mobile layouts. Record any page that is intentionally excluded from navigation but should remain reachable.

Create a separate media checklist before rebuilding. For each approved logo, image, document, or icon, record where it appears, who owns it, and whether a higher-quality original is available. Do not copy theme files, extension code, account settings, unpublished drafts, form submissions, or administrative exports into Workganic page content.

Identify behavior that may come from a WordPress theme or extension rather than the visible page itself. Recreate only the approved visitor-facing result with Workganic controls. Flag stores, memberships, account areas, calculators, custom scripts, and other specialized behavior for a separate decision instead of assuming that a visual copy will reproduce them.

## Plan the Workganic page map

Match each source page to a Workganic page and choose a native block for every visible section. Mark anything that does not have a safe native equivalent for manual review. Common examples include custom scripts, store functions, membership areas, embedded account portals, and specialized extensions.

Do not paste executable code from the old site into page content. Recreate the visible result with supported blocks and approved media.

## Build in a draft

1. Open Marketing and select **Website Builder**.
2. Select the intended site or create the approved site structure.
3. Create each page with the planned title and path.
4. Choose **Add Block** and rebuild the page section by section.
5. Upload only approved public media and files.
6. Recreate links and forms using supported controls.
7. Complete **Page Settings**, **Site Settings**, and **SEO & Social**.
8. Keep the new pages in draft while the full site is being checked.

Build shared site elements first, then the home page, primary landing pages, and lower-priority pages. This makes navigation, colors, type, buttons, and spacing consistent before the full site is reconstructed.

For practice and demonstrations, use invented names and information. Do not use real client or applicant information as sample page content.

## Review the private test site

Select **Open Test Site** and compare the reconstruction with the approved source inventory. Review every page at desktop and mobile widths.

Confirm that navigation is complete, content is accurate, brand styling is consistent, images are sharp, downloads work, forms use the approved fields and consent, and important old paths have an intentional destination. Test form behavior with synthetic information only.

For a close visual match, compare the source and private test site at the same desktop and mobile widths. Check section order, content width, type hierarchy, colors, spacing, button treatment, image crops, header behavior, footer content, and form states. Match the approved experience, not accidental theme defects or obsolete content.

## Prepare cutover and rollback

Publishing the Workganic pages and directing a domain to them are separate changes. Before either change:

- Preserve the last known-good source site and its page map.
- Confirm who controls the domain and who is authorized to change it.
- Define the cutover window and the person who will approve it.
- List the checks that must pass immediately after cutover.
- Define the condition and procedure for returning traffic to the prior site.

Do not change domain settings merely because the private test site is complete.

## Publish and verify

After approval, select **Save Changes** for each standard marketing page that should become public. If the migration includes a Documentation page, select **Review & Publish** for that page and confirm the public-content review for the exact draft. Then select **Open Published Page** and verify each published Workganic page before any domain cutover.

After an authorized cutover, verify the public domain separately. Check the home page, navigation, important old paths, redirects, forms, confirmation behavior, mobile layout, secure connection, search title, search description, and social preview.

## Migration completion criteria

The migration is complete only when the approved page map is accounted for, the published Workganic pages have passed review, the authorized domain cutover is complete, the public domain has passed acceptance checks, and the rollback copy remains available for the agreed period.

> A similar-looking home page is not a complete migration. Pages, links, forms, search details, mobile behavior, redirects, publishing, domain cutover, and public verification must each be accounted for.