Which digital layers does the buyer expect to receive?
List the actual domain names, registrar accounts, DNS services, hosting, website files, email, and relevant integrations. Identify the seller, agency, or other party that controls each layer. A website address in a brochure is only a starting point.
Use the selling hub to connect those assets to the exit plan. The buyer needs a supported handoff of the layers it expects to operate. One clause saying website included cannot explain every provider account, license, or control question.
A domain-control map links each digital layer to its rights, account controller, authorized contact, provider terms, proposed action, and tested completion. It exposes dependencies. It does not make account access proof of ownership or approve a transfer from the website's appearance.
Who is the registered holder and who controls the registrar?
Request the actual registration and account evidence through authorized channels. A public lookup may not reveal all private registration details. The seller should identify the holder and approved contact without exposing unnecessary identity or recovery information in the deal package.
Compare that evidence to the included-asset terms. A domain registered in an owner's, agency's, or related entity's name can raise different questions from one held by the operating company. Counsel and the provider should assess the actual authority and process.
The sale preparation guide helps assign those questions early. A buyer should not discover after closing that the needed registrant contact is unavailable or the seller only had access to a website editor.
Which transfer policy should be read?
ICANN's domain-transfer index identifies the updated policy and its implementation timetable. It distinguishes that version from superseded policy pages. Use the relevant current text rather than assuming the first search result is controlling.
The linked updated Transfer Policy addresses inter-registrar and change-of-registrant processes, authority, and conditions. Apply its actual scope to the domain and provider facts. A policy for named registrar and domain categories is not a universal contract for every website asset.
Ask the registrar to confirm the applicable process, status, and accepted timing. A planned buyer change can involve different steps from moving to another registrar. Keep those events separate in the closing schedule.
How can change order affect a transfer lock?
The updated policy describes a sixty-day inter-registrar lock following a change of registrant, with a stated possibility for the registrar to allow opt-out before the change request. That condition matters when the plan also includes moving registrars.
Confirm the actual registrar's response before making changes. Do not assume an opt-out is available or that it can be chosen after the event. The buyer and seller need a supported sequence, not a universal promise of immediate transfer.
Record the actual lock, its basis, and the next allowed step. A lock on a move between registrars does not mean every website task has stopped. The team should check its scope. A domain move and a working website are separate questions.
Why are DNS and hosting separate from registration?
Identify where DNS is administered and what services its records support. Website, email, forms, and other functions can depend on different records. A registrar transfer does not establish that all those settings remain correct or under buyer control.
For hosting, request the actual provider, account terms, files, deployment process, and authorized access. The buyer may plan to keep the service or migrate it. Those paths need their own provider and technical review.
Keep included files and licenses explicit. A host account can hold a working website without conveying every theme, image, custom code right, or third-party service. Counsel should assess actual asset terms while technical staff test the relevant function.
How should email and recovery dependencies be mapped?
Identify business mailboxes, domain-based account logins, recovery contacts, and relevant provider roles. A seller email account may be needed to approve another change. Moving or closing it too early can affect the supported sequence.
Review the actual email service and transfer plan. A domain update does not prove mailbox data, permissions, forwarding, or delivery are ready. Keep historical data scope and permitted access separate from whether new messages work.
The seller-document guide helps record those dependencies. Use controlled access for private messages and identity details. The buyer needs supported control, not unrestricted copies of every owner's personal account.
What should the control map show?
Use one row per layer or clearly defined asset group. Link evidence in the controlled file. Status should distinguish proposed access, accepted provider action, completed change, and tested function.
| Layer | Evidence to obtain | Handoff question |
|---|---|---|
| Domain registration | Actual holder and registrar response | Who may authorize the change? |
| Registrar account | Accepted role and provider terms | Who can manage the registration? |
| DNS | Actual service and record plan | What functions depend on it? |
| Hosting | Contract, files and approved access | Where does the website run? |
| Website rights | Included assets and license review | What may the buyer use? |
| Mailbox, role and migration scope | What messages and control continue? | |
| Recovery and integrations | Authorized contacts and dependencies | What else must remain available? |
A green status should have a named evidence source and date. A login test proves a particular function at a point in time. It does not prove every right, service, and dependency in the map is complete.
How are access and secrets handed over?
The FTC security guide supports appropriate authentication and access controls. Use named authorized roles and secure transfer processes instead of a broad shared-password document.
Check recovery routes and accepted role changes before removing needed users. The provider process should remain usable during the handoff. After the supported change, review old access according to the actual plan.
Keep secrets and private identity documents out of public pages and general deal files. Security guidance helps manage access; it does not establish that the seller legally owns the domain, website code, or customer data.
Which functional tests matter before ending old service?
Test the agreed website routes, business email, relevant forms, integrations, and administrative access through the approved plan. Record scope and outcomes. A home page loading once does not establish every dependent function.
Use controlled tests that avoid unintended customer activity. The technical team should choose the actual checks and identify their limits. A test result is evidence of the tested function, not proof of preserved ranking or every future delivery.
For an illustration, assume four planned checks: website, email, form routing, and buyer administration. If only website loading is confirmed, three checks remain open. These chosen counts are not target facts or a universal testing standard.
What if an agency holds a required layer?
Obtain the actual agency agreement, account role, included work, and provider requirements. Ask what can transfer, what must be licensed, and what service may continue. An agency's willingness to help is useful but does not replace the relevant evidence.
Have counsel review asset rights and contract terms. A domain controller can differ from the website designer or email provider. Each layer should have a supported decision and responsible contact.
The sale process guide connects open items to closing. If a dependency remains unresolved, keep it visible in the operating plan. Do not present all digital assets as fully handed over because the main URL still works.
What sequence supports domain and website control?
- Inventory actual domains, rights, controllers, providers, and dependent services.
- Verify authorized contacts and applicable transfer or assignment requirements.
- Agree on the change order, supported timing, access, and backup process.
- Test the relevant website, email, administrative, and integration functions.
- Confirm completion before ending required old service or claiming full control.
The result is a traceable handoff across the digital layers. It lets the buyer distinguish registration changes, working logins, included rights, service readiness, and performance evidence rather than treating them as one domain transfer.