Inheriting a website can mean inheriting a business asset without its instruction manual. The pages still load, but nobody is certain who receives renewal notices, which account controls the domain, or whether the last working backup can actually be restored.

The first step is not necessarily a rebuild. It is establishing enough control and understanding to make a responsible decision. A new developer should be able to explain what they have inspected, what remains uncertain, and which changes should wait until the existing site has been preserved.

Treat the handover as a small project with its own scope. That gives your business a useful outcome even if you later decide to keep the website, repair a few problems, or replace it entirely.

Protect the business while you learn the system

Begin with the customer tasks that must continue working. List the inquiry routes, booking process, store checkout, account access, and documents people rely on. Record any known failures separately from improvements you would like to make.

Identify upcoming deadlines: domain renewal, hosting payment, software subscriptions, campaign launches, and operational commitments involving the website. Ask who receives each notice and whether the relevant business contact is still available.

Avoid making several changes merely to establish that a new person is in charge. Changing hosting, software, content, and account access together can make an existing problem harder to understand. Where urgent action is necessary, record what changed and why.

Choose one internal person to coordinate the transition. They do not need to understand every technical detail. They need to keep the inventory, unanswered questions, approvals, and supplier conversations in one place so the work does not depend on scattered memories.

Separate an emergency from an incomplete handover

A missing document is a question to investigate. A confirmed security incident or a critical customer task that fails needs a defined response. Ask the developer to distinguish those situations and explain the immediate recommendation before treating every uncertainty as an emergency.

Inventory accounts by function, not by password

Create a list of the services that keep the site operating. Include domain registration, DNS management, hosting, website administration, email delivery, analytics, search reporting, payment integrations, and paid software where relevant.

For each service, record the provider, account owner, billing contact, renewal arrangement, authorized administrators, and recovery process. The inventory should identify where control belongs without becoming an unprotected list of secret credentials.

Check whether your business can recover access independently of the previous developer. A familiar email address in an old invoice does not establish that the right person can administer the account today. Use each provider’s authorized process to confirm the arrangement.

Do not assume the website login controls the domain or hosting. Treat each service as a separate responsibility until the inventory demonstrates how they connect. Ask the new developer to draw a simple dependency map that your coordinator can understand.

ICANN’s registrant responsibilities place responsibility for domain registration and use on the registrant and require current account data. That is a reason for the owner to understand domain administration rather than leaving it as an unexplained technical detail.

Preserve a recoverable baseline before changing anything

Ask the incoming developer to propose a safe way to preserve the existing site and its relevant configuration. Define what the copy includes, where it will be stored, who can access it, and how a restore would be checked.

A folder named backup is not the same as an agreed recovery process. Ask for evidence that the necessary material has been captured and that a suitable test copy can be brought into a usable state. Keep customer information protected during that work.

Record the condition of the customer journeys before the handover. Use fictional test details where possible and note existing failures. This protects both your business and the incoming developer from later confusion about whether a problem began during the transition.

Do not send the entire website or customer database casually between suppliers. Agree on appropriate handling and access before a copy is transferred. The need to inspect a system does not automatically justify sharing every piece of information it contains.

A man speaks on a phone and writes notes beside an open laptop at a table.

Review software support without upgrading blindly

Have the developer identify the platform, themes, extensions, custom components, and server software that matter to the site. Ask which versions are installed and which require attention, rather than accepting a general statement that the website is old.

The timing can matter. As of this December handover, PHP’s supported-version schedule lists security support for PHP 8.1 ending on December 31, 2025. If your site uses that branch, ask for a compatibility assessment and an upgrade plan rather than waiting for the support deadline to become a surprise.

That does not mean changing the server version without testing. Your developer should explain what depends on it, how the proposed version will be checked with the application, and what the fallback plan is if an important function fails.

Separate unsupported components from components that are merely unfamiliar to the new developer. Ask for the evidence behind each recommendation. A custom feature may need documentation or focused testing rather than immediate replacement because it does not match someone’s preferred setup.

Make the risk list decision-ready

For each concern, ask for the observed condition, the possible business effect, the recommended next step, and the confidence level. Keep unknowns marked as unknowns. An assessment is more useful when it helps you choose priorities than when it makes every item sound equally alarming.

Re-establish reporting access and ownership

Find out who can see and administer the reporting tools your business relies on. Confirm the correct website property and identify accounts that still have access. Do not assume that a dashboard screenshot means your business controls the underlying service.

Google’s site ownership verification guidance explains that a verified owner has the highest degree of permissions in Search Console. It also notes that owners can access sensitive search information and perform actions affecting the site’s presence. Treat that access as part of the handover, not an incidental reporting convenience.

Have the appropriate administrator review owners and users through authorized processes. Record who should retain access and what must be changed when the previous relationship ends. Coordinate changes carefully so that essential reporting or integrations are not interrupted without a plan.

Preserve useful historical reports and document the existing measurement setup before replacing tags or properties. A transition should not create an unexplained gap that makes later performance questions harder to answer.

Understand custom work and recurring obligations

Ask for a description of custom features that a standard platform installation would not explain. Identify their purpose, where they are maintained, which external services they depend on, and how staff use them.

Review licenses and subscriptions with the people responsible for the accounts. Some services may be billed directly to your business; others may have been supplied through the previous developer’s arrangement. Record what can transfer, what needs a new subscription, and what needs clarification before the relationship changes.

Do not treat “you own the website” as a complete inventory of rights and dependencies. Ask about custom code, design assets, photographs, fonts, purchased software, and the ability to move the site. Get appropriate legal advice where the agreement or ownership terms are unclear.

Use the website services overview to frame the disciplines your handover may involve. The assessment should identify which work is necessary now and which can wait, not turn every dependency into a reason to commission every available service.

A man in a yellow hoodie writes on a paper checklist beside a monitor and laptop.

Request a practical handover record

Ask the outgoing provider for the material your agreement entitles you to receive. Keep the request specific: service inventory, configuration notes, relevant code and assets, renewal information, operating instructions, and a list of outstanding issues.

Use professional, factual language. An incomplete handover does not by itself establish bad intent. Older arrangements may simply have relied on one person’s memory. Your goal is continuity and clarity, not an argument about who should have documented something years ago.

Have the incoming developer review the supplied material and identify missing pieces. Record which gaps can be resolved by inspection and which need a supplier response. Avoid making continued progress depend on an unanswered question when there is a safe, authorized way to verify the fact.

Agree on a final access review when the handover ends. Identify the business owner responsible for approving the transition and the person responsible for confirming that the agreed changes were completed.

Document the ordinary jobs as well as the infrastructure

The person maintaining the website needs to understand what staff actually do with it. List recurring jobs such as changing a service description, adding a product option, reviewing an inquiry, issuing a refund through the appropriate system, or replacing a downloadable document. Choose only the tasks relevant to your business.

Have a staff member demonstrate the current process while the incoming developer observes. Record the expected result and any manual steps outside the website. A technical handover can otherwise miss the spreadsheet, email notification, or approval that makes the workflow usable.

Ask for instructions that another employee could follow. They should identify the correct system, the approval needed, how to check the result, and whom to contact if something goes wrong. Keep sensitive access information in the approved account-management process rather than embedding it in a general staff guide.

Keep temporary arrangements visible

A transition may require a temporary contact, a manual check, or a deferred change. Write down the owner and review date for each arrangement. Do not let a workaround quietly become the permanent process because everyone assumes someone else will replace it.

Schedule a review after the transition to check the open items and the ordinary staff tasks. Use that meeting to confirm what is complete, what remains uncertain, and which next steps have been approved. Keep the record with the handover material.

Commission the next step, not an automatic replacement

A useful first engagement can end with a dependency map, verified recovery baseline, account inventory, risk list, and prioritized recommendations. Define those deliverables before the assessment begins so you can evaluate whether the work answered the right questions.

Separate urgent repairs from maintenance and larger improvements. Ask for estimates and assumptions for the next stage. A recommendation to rebuild should explain why repair or continued operation is not the more appropriate choice for your requirements.

If you are considering Motta Industries, review how we approach client work and ask for the same clarity you would expect from any incoming developer. The purpose of the handover is to make the website understandable and manageable for your business.

Contact us with the customer tasks you need to protect and the information you already have. Start by establishing control, preserving what works, and identifying the decisions that genuinely need attention. The question of rebuilding can follow evidence rather than uncertainty.