Website Migrations

Website migration tools help you bring supported source-site content into Hiveality as editable drafts.

Start a migration with Agent Bee

During guided setup, choose Migrate my site and add the public source URL. Bee scans the site when possible and can show discovered URLs, content counts, and a homepage preview in the Plan tab.

Choose one of two starting paths:

• Create homepage preview: recreate only the source homepage, choose how closely the draft should follow the current design, and pause for review before anything else is migrated.
• Request migration assessment: select the content and systems that need review, add any deadline or must-keep details, and send the request for scope, timing, and next-step review.

Before either path continues, confirm that you own or have permission to reproduce the source site's content, branding, images, and design. Do not add passwords or private access details to the setup chat. If the automatic scan cannot finish, the saved source URL and the details you entered remain available for manual review.

Import blogs, products, and team content

Use Import Blogs, Store Products & Team for supported non-PatientBase source sites. The importer can discover URLs from a sitemap or homepage crawl, then lets you choose which content to import.

Blog discovery recognizes common WordPress and Substack patterns, including Substack /p/ posts, blog subdomains, dated blog URLs, and custom blog paths you provide.

You can also ask Agent Bee to survey an old WordPress, Squarespace, Wix, Duda, Substack, or other public blog before importing it. Bee reports the discovered post count, checks a sample through the real importer, and gives a high, medium, or low confidence result before asking whether to continue. An approved import runs in the background, preserves the source title, address, date, author, categories, and tags when available, and saves external images in Hiveality.

This assisted path can create published posts or keep the entire imported batch as drafts. Choose drafts when you want to review titles, links, images, and layout before anything appears on the public blog. Start with a small batch when the survey confidence is not high, then ask Bee for the migration status and review any failed URLs before moving the rest.

The selected draft or published choice is kept as a background blog import continues. Imported posts retain the source publication date when it can be read reliably. A draft with a missing or unclear source date stays a draft without an invented date and is flagged in the migration report for review. Check source dates before publishing those posts.

The source survey keeps category, tag, author, and other archive pages out of the post list, and uses the source's reported total when a WordPress site provides one. During import, an existing post with the same address is treated as already present rather than as a new failure. Hiveality also retries a background blog move that stops making progress, while keeping genuinely failed items available in the migration status for review.

Older WordPress posts with recipe-style blocks or unusual paragraph markup keep clearer spacing between sections after import, so drafts need less cleanup before publishing.

Elementor blog imports recover the authored post body when it is stored inside Elementor's page data instead of the standard WordPress content field. Imported titles, excerpts, image labels, and other blog details also decode common HTML entities while preserving real apostrophes. Review a few posts with quotes, ampersands, and accented punctuation before publishing the full batch.

Author detection now prefers a readable person's name from structured details, author links, or the visible byline instead of saving the surrounding profile card as the author. Review a sample of author-heavy posts before a large import.

For WordPress posts, the import also checks the source post details for the authored title and display name. This helps keep a website name from being added to every post title and avoids showing a site login as a person's byline. If the source does not provide a readable person's name, the post can arrive without a byline; add one while reviewing the imported post. Ask Bee for migration status to see issues beside the affected posts, including the source URL of a media item that could not be imported. Check whether that item still works on the old site before deciding whether to replace it.

Media and link handling

For supported page and blog imports, Hiveality re-hosts external media by type so imported drafts depend less on the source site after migration.

• Images are saved into your file library and rewritten in the draft.
• WordPress featured images prefer the widest available source and, when it can be verified, the original full-size file instead of a small resized copy.
• Squarespace width variants of the same image reuse one saved file, reducing duplicate library items without changing audio or document imports.
• Audio files and linked documents, such as PDFs, are saved into your file library.
• Direct video files are imported into your video library and rendered with the native video player where supported.
• Linked audio and video downloads are saved into your file library instead of continuing to depend on the source website.
• Supported YouTube, Vimeo, Facebook, and Spotify frames in imported blog posts stay in their original position as editable Embed Code widgets. Other frames are removed for safety and listed for review when possible.
• If a supported frame is missing from a post that was imported earlier, an approved connected workflow can add the embed beside the correct paragraph without re-importing the full post.
• Bare email addresses and bare website domains in imported links are repaired into usable links when Hiveality can safely infer the destination.
• Links back to the old domain are changed to local post, page, or redirect paths when a clear match exists. Unmatched links remain unchanged and are listed for review instead of being guessed.

Imported editable page sections also preserve more source structure:

• A multi-column footer stays one footer instead of being repeated as a feature row.
• Separate footer regions remain separate when they are authored as sibling zones inside the same footer.
• Linked cards keep separate icons, headings, descriptions, and destinations.
• Buttons inside cards remain editable buttons, including cards that also contain lists.
• Boxed card borders are less likely to become an extra divider inside the imported card.
• Body copy authored at 14px remains body copy instead of inheriting the website's small-text font treatment. Explicit small-text markers still use the saved small-text style.
• Repairs that split merged copy back into headings and paragraphs can preserve the original wording while restoring the intended structure.

Import reports now include visible-copy retention alongside media, button, and form checks. A substantial copy shortfall is called out for review, and the report also shows when divider widgets were created during conversion. Review these diagnostics before publishing a large or highly structured import.

Always preview imported drafts before publishing. Some complex embeds, private source files, or unsupported video providers may still need manual replacement.

PatientBase review and recovery

For supported PatientBase migrations, the sitemap review can scan likely funnel pages before you start the import. Detected funnel steps move into the

Funnel classification, and the review table shows whether a URL was detected from funnel metadata or from a path signal.

If the scan pauses on a large sitemap, use Continue scan to review the remaining URLs before starting. Migration reports also show startup warnings and page-level warnings, including funnel steps that need manual follow-up.

Checkout-like PatientBase widgets and checkout code blocks are mapped to native checkout placeholders instead of plain text. Review those placeholders after migration, attach the correct products, and confirm the checkout copy before publishing.

Imported PatientBase headers keep the source navigation structure without carrying over the source platform's default blue hover background. Preview the header after import and choose a hover treatment that fits the new site's Brand Kit.

PatientBase page conversion also preserves multi-image galleries as editable Gallery widgets, including supported autoplay and arrow choices. Nested portrait images keep their source proportions while adjacent text fills its new column, and source body-copy sizes are less likely to be narrowed or styled as small text twice. Review image-heavy profiles, galleries, menus, and long service pages at desktop and mobile widths before publishing.

Imported columns now keep more of their source padding, borders, and shadows, including narrow frames that should stay crisp rather than looking blurred. Background images in source styles with encoded quotation marks are also less likely to disappear. Check desktop and mobile image sections against the source before publishing, especially where a background changes at smaller widths.

Empty template rows that contain no content are skipped during PatientBase conversion, preventing large blank bands from appearing between a page hero and the first real section. Intentional spacer content remains in place.

Supported imports also preserve more typography and layout details from the reviewed source: distinct text-palette colors, regular italic Google font faces, available Google font variants, image-only spacer columns, paragraph spacing inside text wrappers, interior image columns, mobile menu styles, and description-only icon sections. When a source family is a real custom font, reviewers can import a supported TTF, OTF, WOFF, or WOFF2 file and register the matching family and face instead of substituting a different font.

Full-height source sections now keep their screen-height layout, and intentional spacer-only sections keep their authored height. Narrow spacers placed beside content remain horizontal breathing room instead of becoming extra vertical rows. If a source signup form cannot be rebuilt, the migration report names the missing form so its audience, consent, notification, and success settings can be recovered before the replacement is published.

Activated Google font families now keep their available regular, italic, and weight variants when migrated content is rendered in the builder and on the live site. Review headings, buttons, navigation, and body copy together after registering a source font because the browser may synthesize a weight that was not supplied by the family.

After a reviewed migration finishes, a connected workflow can preview the old paths it can map to imported pages, posts, products, team profiles, funnels, or saved destinations, then create missing 301 redirects after approval. Existing redirects are preserved, uncertain destinations are skipped, and incomplete batch results stay out of automatic redirect generation until the remaining items are reviewed.

For funnels, the first step resolves to the funnel's main path rather than a second step path that would send visitors back and forth. The review also follows proposed destinations for several hops and leaves out any rule that would return to its own source. Equivalent existing rules, including common regular-expression forms, are recognized before new redirects are created.

Native form markers and common email-field meaning are retained when the source provides enough evidence. Funnel imports can be limited to the steps that completed review, leaving uncertain or interfering embeds for manual follow-up instead of importing them automatically.

Funnel source paths keep the source site's capitalization and underscores while Hiveality prepares clean destination addresses. Captured button labels and safe destinations are also recovered from reviewed source data when the visible button markup is incomplete.

Fixed-recipient team notification steps stay flagged for manual replacement instead of being converted to messages for the enrolled contact. Review those warnings and recreate the intended team alert before activating an imported Flow.

Migration reviewers can record a page outcome, notes, evidence links, and separate presentation, configuration, and transaction checks in the migration report. Supported image, gallery, spacer, and global-style button repairs save a recovery point and update the draft; preview and publish remain deliberate review steps.

PatientBase imports now bring more of the source site across as native, editable content:

• Every selected funnel gets its own imported page instead of stopping at a fixed number of funnels. Any selected step that could not be queued is named in a startup warning.
• Pop-up forms become native Form widgets with the source fields, background, overlay, headings, and button links. Anything that could not be carried over is listed in the report.
• Quizzes are rebuilt as native quizzes (single or multiple choice, contact gate, scored or category-based results). The report adds a review item that names the quiz categories and the candidate result pages so you can confirm the outcome mapping.
• Forms are registered on every imported page and funnel step, and a form widget reused on several source pages produces a separate form for each page.
• Sections hidden on phones in the source stay hidden on mobile after import, and the first row no longer keeps a source entrance animation.
• Custom fonts declared by the source are detected with their individual font files and re-hosted, and only fonts the Google catalog recognizes are labelled as Google fonts. Unresolved families are reported for follow-up.
• Imported store products are matched to an existing product before a new one is created, and source subscription and payment-plan blocks become recurring or installment prices.
• Funnel steps that redirect to a sign-in page are flagged as login-gated so you can capture them manually.

Use Retry queued on a migration report when queued or stuck items should be scheduled again. If a batch blog import reports missing blog items, the report can recover the missing blog rows and then retry the remaining work.

Lagacy System migration workflows

When Lagacy System migration tools are available for your website, the migration dialog includes three workflow areas:

• Brand Kit: extract colors, fonts, logos, and brand direction before building pages.
• Background Migration: select source pages and create editable Hiveality pages in the background.
• Email Marketing: validate a captured bundle and import draft flows, draft campaigns, and standalone draft emails.

During Background Migration, review the classification table before starting. Hiveality can scan selected source pages for embedded funnel details, move detected funnel pages into the Funnel classification, and show the detected step paths for review.

Use the header and footer import options when you want the source homepage header or footer copied into the new site shell before migrated pages are created.

Import email marketing drafts

The capture package footer shows the installed version and includes

Download latest and Open update page actions to help you refresh the package before a larger capture session.

When captured flow names are too generic, the capture tool asks you to confirm the name and lets you rename it later. Captured email snapshots can also be matched to the first available flow email slot when the source flow is detected, which reduces manual slot cleanup before import.

For larger email marketing migrations, the capture tool can bulk capture a flow with its email previews, capture campaign rows and previews in batches, and auto-scroll longer campaign lists until the requested count is reached.

Imported email drafts now preserve more common source sections as editable blocks, including image/text/button rows, background call-to-action sections, two-column layouts, relaxed text spacing, and intentional blank lines.

When imported emails link to files such as PDF guides, Hiveality uploads those files into Files and rewrites the draft email links to use the saved file URLs.

What validation checks

Validation summarizes the captured bundle before any drafts are created:

• Flow count, email steps, delays, campaigns, and standalone email snapshots.
• Missing flow or campaign email snapshots that may need review.
• External images and links that will be carried into the imported drafts.
• Delay steps that cannot be converted cleanly and need manual review.

Review imported drafts

After import, open each created flow, campaign, or email from the result links. Confirm the subject line, images, links, timing, header/footer choice, and any warnings before publishing or sending.

Related guides

• Flows (Automation)
• Campaigns
• Email AI Generation
• Troubleshooting

Check fonts, labels, and redirects after import

New PatientBase imports preserve widget-level mobile and desktop visibility, decode labels such as button and menu text, and remove empty paragraphs at the edges of text widgets. Supported inset frames become column borders. Checkout sections become native checkout placeholders for configuration instead of a block of copied text; review and connect the intended checkout before launch.

Brand capture checks whether Google Fonts actually serves each family. When source font files are available for a custom family, Hiveality can save those files for the imported site. Fonts found on inner pages are also checked, and unresolved families are listed for follow-up. These improvements apply to new imports; review earlier drafts separately.

Generated migration redirects skip paths already used by a published page, active funnel, or public blog post. URLs you did not select for import are reported for review rather than automatically redirected to the homepage.

New PatientBase imports combine adjacent list fragments that share the same style and structure into one editable list. Lists with different styles stay separate. Font discovery also recognizes quoted font names inside page content. Review list spacing and fonts in the imported draft before launch.