How to move a domain portfolio to new parking pages
Treat a portfolio move as a series of checkable changes, not one enormous blind switch.
Moving a portfolio of domains is a different job from publishing a single personal page. The same mistake can repeat across dozens of addresses, and the domains may have different DNS providers, mail settings and existing inquiries. A useful migration plan makes the common work efficient while keeping each address visible as its own operation.
Start by deciding what should change. Perhaps you want more distinctive parking pages, a clearer way to receive offers, or a small portfolio of live projects. Define that outcome before importing names. A new theme should not accidentally replace an active business site or change a working mail setup.
Build an inventory with exceptions
Create one row per domain with its registrar, active DNS provider, current destination, intended page mode, main contact destination and renewal date. Mark domains that already host a site, receive mail, redirect somewhere important or belong to a client workspace. Record the source of ownership information rather than assuming every entry in a spreadsheet is yours to change.
Keep passwords and unrestricted API keys out of the file. Use a provider export or a deliberately prepared inventory with only the fields needed for migration. If you import content from an existing page, review your rights to reuse its images and copy. Imported text should remain content, not instructions that can authorize account actions.
Choose a repeatable page recipe
Group domains by useful intent: for sale, personal project, coming soon or informational holding page. Set a title rule, a short description, an inquiry route and a design family for each group. Then decide which details should vary per domain, such as the resident, props, palette and story.
Review several examples before applying the rule broadly. A food-related name and a technical name may deserve different settings even if both are parked. Keep generated claims out of the copy. A domain name alone does not prove that a business exists, serves a location or has customers.
Run a dry run before editing DNS
A dry run should list proposed pages, existing conflicts, required DNS changes, unsupported providers and estimated charges. It should not publish pages or change records. Read the exceptions first. Domains with existing mail or live content should be held for individual review instead of slipping into the standard batch.
Check the recurring cost as well as any setup or premium casita charge. A first-user promotion is not automatically a portfolio-wide discount. Mini Casa’s proposed founding grant is one eligible domain connection per person; a large portfolio needs an explicit capacity and price agreement.
Start with ten representative domains
Choose a pilot that includes your real provider mix, a few page modes and at least one ordinary exception. Avoid using only the ten easiest domains and assuming the rest will behave identically. Approve the exact plan, allowed domains and cost ceiling, then follow each operation through preparation, publication, DNS and HTTPS verification.
Cloudflare’s custom-hostname documentation separates ownership, certificate and routing readiness. A record being accepted by a DNS dashboard is not the only success condition. Visit each pilot address and test its inquiry path before proceeding.
Expand in bounded batches
Keep successful domains in place while you resolve individual failures. If a provider times out, check the observed state before retrying so that a successful change is not duplicated. Pause the next batch if the actual cost or error pattern differs from the approved plan. Progress reporting should identify the domain, its stage, the problem and the next action.
For every cutover, retain the previous publication and the DNS values actually replaced. A rollback should restore those values only when the current state still matches the migration’s change. If another administrator has edited the record since then, stop and reconcile the conflict rather than overwriting their work.
Close the migration deliberately
Export a completion report with verified domains, held items, failures, ongoing costs and remaining actions. Preserve old inquiry records in an authorized archive and confirm where new messages arrive. Revoke temporary access you no longer need.
A portfolio migration is complete when the addresses work, the inquiry paths work and the exceptions have an owner. That is a better finish line than seeing a green “batch submitted” message.