Use PD Azure DNS’s BIND-format workflow to move ordinary DNS record data. The module’s import is different from running a separate Azure CLI import, so do not assume another tool’s merge or replacement behaviour applies here.

Prepare the record input

Keep the source file and identify the exact target subscription, group and zone. Review website, mail, verification and child-domain requirements before a migration. Standard record data does not capture every provider setting, signing key or parent delegation.

For an ordinary-record migration, prepare the supported records you intend to add. The current module import compares the staged file with live values, skips duplicates and already-present values, and leaves provider-owned SOA and apex NS alone. Child-domain NS delegations are different records and need their own review. The record file does not include signing keys or other Azure configuration.

Apply to the reviewed zone

1. Open Azure DNS → Zones and the intended zone’s records.
2. Use its available import control and supply the reviewed BIND data.
3. Check the target and displayed input information before applying.
4. Inspect the result and actual record sets, including any reported refusal.
5. Compare the intended names, values and TTLs with the live data.

Imports add values for ordinary multi-value record sets; values absent from the file are not automatically removed. An existing value is skipped rather than rewritten solely to change its TTL; adding a missing value can affect the shared record-set TTL. A CNAME has only one target, so a new CNAME value can replace the old target. Do not treat this as an exact zone rollback.

The planned missing records are checked against the owning customer’s allowance before provider writes. A later Azure refusal can still follow earlier successful rows. Reconcile the actual state before repeating the file. If provider authority records are refused, keep the error for support rather than deleting the zone to make the import proceed.

Export and complete a cutover

Use the available export/download control to save the current BIND record file. Keep signing configuration and any other settings separately. A file containing authority records is not proof that an unedited round trip will restore everything correctly.

Change registrar delegation only after the destination is ready, and retain the previous DNS during the cache transition. Use the delegation guide and snapshot limitations guide for those separate tasks.

Check the imported records

Your hosting team should compare the staged file with the current destination and review the missing-record count and owning customer’s allowance. The allowance check happens before import writes, but a later Azure refusal can leave an earlier row added. Check child NS delegations separately from provider-owned apex NS/SOA. Describe affected rows rather than attaching the whole customer zone file.

See the PD Azure DNS Blesta guide for related tasks, or explore the module.