A domain transfer checklist for portfolio operators

What should a portfolio transfer checklist cover?

A domain transfer changes the sponsoring registrar. Before starting, check eligibility, authorization, contact access, pricing, and the current DNS arrangement. Transfer one controlled batch at a time and verify its outcome. An authorization code is sensitive, and a registrar transfer should not be treated as an instruction to replace nameservers or hosting.

Consolidating a portfolio can simplify daily work, but a transfer is more than moving a row between spreadsheets. The domain, registrar account, authorization, and DNS arrangement must remain clear throughout the process.

The AIvikings portfolio page describes transfer-code access and domain administration. Use those capabilities as part of a deliberate transfer plan. A name held elsewhere does not become manageable in AIvikings merely because you add it to a candidate list.

This is one part of the domain portfolio management workflow, which connects account records, spending decisions, batch execution, and verified results.

What should you check before requesting a transfer?

Identify the exact domain, its current registrar, and the account authorized to control it. Confirm that the proposed move has the owner's approval and that the destination account is the intended one. Resolve ownership or access disputes before treating the name as ordinary portfolio work.

Review the domain's current status and applicable eligibility conditions. Registration age, a recent transfer, contact changes, locks, or a dispute can affect the process. Rules differ by extension and circumstances, so avoid applying a remembered rule to every holding.

ICANN's transfer-policy overview is a useful starting point for relevant gTLD transfers. Check current registrar guidance and any extension-specific requirements as well. This checklist is an operational sequence, not a substitute for those conditions.

Make sure the responsible person can receive and act on required communications. A monitored address is useful only if someone actually owns the transfer decision and knows when to expect a request.

How do you handle authorization codes?

Treat transfer authorization codes as secrets. Obtain the code through the authorized account process and provide it only where the transfer workflow requires it. Do not put it in a shared portfolio report or an ordinary chat summary.

AIvikings documents code retrieval and regeneration in its MCP tools reference. Read the actual behavior before using either operation. Regenerating a code can invalidate an earlier one and disrupt a transfer already in progress.

Keep a record that the code was obtained or rotated without copying the code itself into the action ledger. The ledger should help an operator trace the process, not become an alternative credential store.

A transfer lock is a separate state to inspect. Do not unlock a broad portfolio as a convenience when only a few names are moving. Scope any authorized change to the exact transfer list.

What should happen to DNS during the move?

Document the current nameservers and where the zone records are maintained. A registrar transfer and a DNS migration are separate changes. If you intend to preserve the DNS provider, make that explicit in the transfer plan.

Check whether any current DNS service depends on the account or commercial arrangement you are leaving. Do not assume that an unchanged nameserver value guarantees the old service will remain available after a transfer.

If DNS must move too, prepare that migration as its own task. Inventory the records, create the destination zone, and define verification for web, mail, and other services. Combining both changes without separate evidence makes later failures harder to diagnose.

Keep the prior delegation information so you can explain unexpected behavior. A domain appearing in the destination account does not prove that all its services are functioning.

How should you budget the batch?

Check the current transfer price and the term treatment for each selected name. The AIvikings catalog distinguishes transfer prices from registrations and renewals. Exact conditions still matter for the name and extension.

Avoid assuming that every transfer adds the same amount of time or that every premium domain follows the ordinary catalog treatment. Record the expected resulting expiry where it can be established from the applicable terms.

Set a batch budget in the currency actually used. Keep unresolved prices outside the executable list until the authorized person decides how to handle them. A transfer list approved for ordinary holdings should not silently absorb an exceptional charge.

If names are near expiry, review the timing and options with the relevant registrar before relying on a transfer to solve the renewal problem. An incomplete transfer is not a substitute for a confirmed extension of the holding period.

How do you execute without losing track?

Start with a small, controlled group. Record each name's starting registrar, status, expiry, nameservers, and intended destination. This gives you an observable baseline rather than a general expectation that the portfolio will eventually move.

Track states such as prepared, submitted, awaiting action, completed, and needs investigation in your own ledger. These are workflow labels; use actual registrar evidence to update them rather than guessing from elapsed time.

Check for required communications and exceptions during the run. A request that was accepted for processing may still need another action. Do not equate a successful submission response with final completion unless the response contract establishes that outcome.

Avoid resubmitting an uncertain transfer merely because the first result was slow. Inspect its current state and seek a clear next step. Repeated requests can create confusion without improving progress.

What proves the transfer is complete?

Verify the name in the destination account, its resulting registrar status and expiry, and the intended lock and nameserver settings. Then verify the services that matter, especially if DNS was also changed.

Reconcile the completed list with the original approved scope. Keep failed and pending rows visible, and leave a next action for each. Update the wider portfolio inventory only when the operational result supports it.

Retain the old record as history rather than erasing the evidence of where the domain was held. That history can help explain invoices, expiry changes, and later ownership questions.