Use Migration → From another provider to move management between DNS providers already connected to PD DNS Manager. Copying records and changing registrar nameservers are separate stages, so plan both before starting a cutover.

Before a change, confirm the provider connection and the actual zone it resolves. With Route 53, name-based operations resolve the first matching hosted-zone name; selecting a familiar domain is not sufficient when AWS holds multiple zones with that name. Have your AWS administrator compare the hosted-zone ID, records and assigned nameservers before proceeding. With Google Cloud DNS, the current connection derives the managed-zone name from the domain. An existing zone with a different native name can appear in a list yet fail to open correctly; establish that mapping with your Google Cloud administrator instead of creating a duplicate zone.

For a PowerDNS backend, module reads and zone-file snapshots omit disabled native record values. Editing an affected record set can rebuild it from the enabled values. If your hosting team uses disabled records, preserve and review the native record set with your DNS administrator before module changes; use your established native management process where those values must be retained. A module export is not a complete backup of those disabled values or other provider settings.

Prepare the destination

Connect and test the target provider, confirm it accepts new domains, and review its permissions, quotas, supported record types and minimum TTLs. Keep a source-zone export and plan for services that live outside ordinary DNS records, including a proxy, website forwarding or email routing.

For a signed domain, remove the old registrar/parent DS record first and allow its TTL to expire while the old zone remains signed before disabling signing. The new provider needs its own signing setup and DS record after cutover; the old signing keys do not move with an ordinary DNS copy.

Review the mandatory dry run

1. Open DNS → Migration → From another provider.
2. Select the source provider and the intended zones.
3. Select a target that is accepting new domains.
4. Review copied records, unsupported types, adjusted TTLs, signing flags and read failures for each zone.
5. Resolve any unacceptable omission before confirming the move.
6. Follow the background progress under Recent migrations and check the verification result for every zone.

The workflow reads back the target records before switching the zone’s management in the module. A failed verification keeps that zone managed at the source; review the listed difference rather than assuming the entire batch succeeded. Verification checks that planned records are present; it does not remove every target-only record. Review those separately. A failed run can leave a new target zone or partial writes. After success, confirm the actual management binding as well as the copied records before registrar cutover. Creation also depends on the target backend’s prerequisites; do not assume a panel provider can create every zone from a DNS record list alone.

Complete registrar cutover

The source copy is left in place. The destination has its own SOA and apex nameservers; update the registrar to the target nameservers only after the verified copy is ready. Preserve needed subdomain delegations and check them as part of the record set.

Keep the source answering through the resolver transition, then verify website, mail and other important names from the destination. DNS migration does not carry Cloudflare’s proxy/security features to another backend. Use the existing-domains-only placement choice to stop assigning new zones to the retiring provider without deleting working source zones.

Check the copied zone and delegation

Your hosting team should compare the dry run, target records, verification result and actual management binding for each zone. A failed copy can leave a created target or partial records while management remains at the source. Preserve the source and review target-only records before another run; verify registrar delegation separately.

See the PD DNS Manager WHMCS guide for related tasks, or explore the module.