Moving an established website is a migration. Preserve its useful content and URL behavior, rebuild the required static output, and make a deliberate domain cutover after verification.
If the main website should remain on its current provider, use an AI companion instead of migrating hosting.
Inventory the current website#
Before changing anything, record:
- Public page URLs, titles, canonical URLs, and important incoming links.
- CMS collections, entries, publication states, and original publication dates.
- Images, fonts, downloadable files, and the rights to reuse them.
- Forms, search, chat, analytics, consent controls, and external services.
- Current DNS records, hosting access, build/deployment instructions, and a known good release.
Use the source repository and authorized CMS export where available. A visual copy of the homepage does not capture the complete website or the source needed to maintain it.
Build the new source and content model#
Create or adapt an editable Astro project and keep static output. Map every retained URL to its new page. Reuse established slugs where possible and define intentional replacements for pages that move.
For editable articles, design CMS collections and templates before importing entries. Preserve publication state: a draft or archived source entry should not become public simply because a migration script encountered it.
Replace server-dependent features with supported platform or external-service integrations. Confirm that critical forms and authenticated experiences have an appropriate destination; a static artifact cannot run the old provider's server application.
Do not assume that a generic redirect configuration file from another host will be recognized. Confirm the current platform's supported redirect path with support for URLs that must change.
Publish and verify before cutover#
Deploy the complete artifact to the existing intended Answer Cloud site identity or a deliberately provisioned migration target. Use staging where available. Check all retained URLs, assets, content, forms, mobile layouts, metadata, generated discovery resources, and a meaningful chat answer.
Compare the new URL inventory with the old one. Check a missing URL, moved URLs, and important externally linked pages rather than only the homepage.
Connect the production domain#
Follow custom-domain setup using the actual returned DNS records. Keep unrelated mail and verification records intact. Only move the intended hostnames, and verify HTTPS and canonical redirects after activation.
Keep the previous host available until the new public destination has passed checks. DNS rollback and Answer Cloud deployment rollback solve different problems: one changes where a hostname routes; the other selects a previous artifact at Answer Cloud.
Close the handoff#
Retain the source, content export, URL map, domain records, and deployment identifiers. Identify remaining limitations and who owns each external integration. Recheck analytics and crawler access after traffic reaches the new host; successful content migration alone does not prove that historical reporting transferred.