A careful handoff.
A confident next step.

Before a new designer changes your website, establish who controls the domain, where DNS is managed, how email works, and which accounts the business depends on. A design project should start with a reliable account map, not a hurried request for every password.

Those services may share a bill or login, but they do different jobs. Moving a website does not automatically require moving the domain registration or email. Changing several services together without understanding their connections can turn a routine handoff into an avoidable interruption.

For a Southwest Florida business changing designers, a written handoff gives both the outgoing and incoming team a concrete checklist. It also helps the owner know what will continue working during the transition.

Separate the domain, DNS, hosting, and email

Create a small inventory before discussing transfers. Record the service, account owner, business contact, renewal date, and person who can approve a change. Keep passwords and recovery codes out of this inventory.

Do not assume the company that registered the domain also hosts DNS or email. Ask someone to demonstrate access to the actual settings. A screenshot of a billing receipt is not proof that the business can manage the account.

Establish business control without sharing secrets

Where supported, give the incoming designer a named invitation with the permissions needed for the project. Retain a business-controlled administrator and recovery method. Confirm that an owner can sign in and receive account recovery messages before the previous team’s access is removed.

Use multifactor authentication and an approved secure process for any credential that cannot be delegated. Do not place passwords, private keys, recovery codes, or domain transfer codes in a shared design brief, ordinary email thread, or public issue tracker.

If a registrar transfer is genuinely required, handle it as a separate controlled step. ICANN explains that an Auth-Code helps identify the domain holder and prevent unauthorized transfers. It is not a general website-design credential.

When account control is unclear, resolve the documented access and contractual questions before scheduling the switch. An operational handoff cannot by itself settle ownership disagreements or override an existing agreement.

Preserve the DNS records that keep email working

Export or document the current DNS zone before making changes. Include record names, types, values, priorities where applicable, and TTLs. Ask the responsible administrator to identify each record’s purpose; keep unknown records until their use has been checked.

Changing a website destination usually involves particular web records. Changing nameservers changes which DNS service answers for the domain, so the receiving DNS zone must contain the required records before that switch.

Pay particular attention to email:

• MX: directs incoming mail to the mail service. Google’s MX documentation explains that delivery depends on these records. A new website is not a reason to replace working mail destinations.
• SPF: identifies authorized sending systems. Preserve legitimate senders, including systems that send website notifications; review changes with the email administrator using the relevant SPF guidance.
• DKIM: publishes information used to verify signed outgoing messages. Preserve the relevant selector records and sending configuration; DKIM uses a public DNS key and a private signing key. The private key does not belong in a handoff spreadsheet.
• DMARC: publishes handling policy and reporting information for domain authentication. Preserve the existing record unless an authorized email administrator is deliberately changing it, following DMARC guidance.

Keep verification records and service subdomains too. Do not “clean up” unfamiliar entries during a launch. The exact values must come from the business’s existing services, not from a generic example copied online.

Agree on the files and connections being handed over

Ask for the material needed to operate the site under the actual agreement: content, authorized images, editable design assets where included, current source or platform access, backups or exports, and instructions for routine updates. Confirm which licenses or subscriptions belong to the business and which require replacement or renewal.

List each form’s recipient, confirmation behavior, file-upload handling, and downstream connection. Include booking links, customer portals, payment destinations, analytics access, and Search Console access where used. Record configuration locations without exposing secret values.

Also capture existing page URLs and important downloads. If the new design changes those addresses, a separate migration plan is needed. An attractive replacement page does not automatically preserve an old link from a customer’s email or bookmark.

For a Legacy Refresh project, agree on these continuity requirements before treating the layout as approved. They are part of what makes the new site usable after launch.

Schedule a controlled switch with a recovery plan

Write the change order in plain language: what will change, who will change it, when it will happen, and what result confirms success. Give one person responsibility for coordinating the switch so two teams do not edit DNS independently.

Keep the existing service available until the replacement has been checked and any agreed transition period has passed. Document how the previous website configuration can be restored if a critical problem appears. If a database or ordering system is involved, also agree how new submissions or transactions will be handled during a rollback.

DNS caching means different visitors can observe a change at different times. Avoid promising an exact universal switch time. Confirm the published records, test from outside the administrator’s own session, and allow for the services involved.

A hypothetical handoff might keep registration and email unchanged while replacing only website hosting. That narrower change still needs form and email tests, but it avoids treating unrelated services as mandatory parts of the redesign.

Sign off on working services and ongoing responsibility

Use a short acceptance record that both the owner and incoming team can understand:

• Business-controlled access and recovery methods have been tested.
• Domain renewal and billing responsibility are recorded.
• Website pages, old important links, and secure connections work.
• An external message reaches the business inbox, and a reply reaches its recipient.
• Website inquiries reach the intended destination and can be answered.
• Booking, portal, and payment links lead to the correct existing accounts.
• Authorized staff know how to request updates and report a problem.
• Unneeded previous access is removed after the handoff is confirmed.

Do not stop at checking whether a form shows a green success message. Verify the message arrived and that the reply path works. Ongoing website care should have a named owner, including a clear boundary between website support and email administration.

Start with an account map

Bring your service inventory and current website concerns to a website design conversation. Local Legacy Consulting works with businesses in Port Charlotte, Fort Myers, and Cape Coral to plan practical transitions with clear responsibilities.