Changing web developers does not automatically mean rebuilding your website. First establish whether the incoming developer can reproduce the current site, make a small change, test the important customer journey and recover from a failed release. Those checks give you a better basis for a decision than either a reassuring screenshot or an immediate rebuild quote.

The first piece of work I would commission is a bounded takeover assessment. Its result should explain what can stay, what needs repair and what remains unknown. A missing login is a different problem from software that cannot reasonably support the next requirement.

Decide what is actually changing

Separate three decisions: who maintains the website, where it runs, and what the business wants it to do. You may need a new maintainer while keeping the same hosting and design. You may need to move one service while retaining the pages. Or the next business requirement may justify a larger replacement.

Write down the reason for the change in observable terms. For example: “We need someone who can add a Hungarian service page and maintain the booking connection.” That is a proposed scope, not a claim about a client result. It gives the incoming developer a concrete task to investigate.

Also identify what must continue working during the transition: published pages, incoming enquiries, booking, orders and staff access. A new design is a separate decision. If you already know that you need one, use the website redesign brief alongside the takeover assessment.

Ask for evidence of the current working system

Start with a map of the live website, not a pile of passwords. Ask the current supplier and your team to identify:

  • The live version: the production address, platform or source repository, and the version currently published.
  • The operating accounts: domain registration, DNS, hosting, content editing and the person responsible for each renewal.
  • The connected services: forms, email delivery, booking, payments, analytics and any CRM connection the site actually uses.
  • The recovery material: relevant source files, content and data exports, uploaded assets, backups and restoration instructions.
  • The change process: how edits reach a preview and then production, who approves them, and how a release is reversed.

For each item, distinguish “identified”, “access confirmed” and “tested”. Someone knowing the hosting company's name does not mean the incoming team can publish a change. A repository containing code does not establish that it matches the running website.

Agree the intended account control and any licensing or transfer restrictions with the supplier. Administrative access and permission to reuse every asset are separate questions. Record unresolved points rather than assuming that a downloaded folder settles them.

Prove the handover with a small change

Have the incoming developer create an isolated preview using the supplied instructions and appropriate test data. Keep test enquiries, payment actions and automated messages away from real customers. A preview that accidentally sends production notifications is not an acceptable rehearsal.

Choose a representative, reversible change. For a bilingual service site, that might be editing one service description in both languages and checking its enquiry path. For an ordering site, agree a test flow that covers the relevant product and order steps without charging a customer.

The receiving developer should be able to show:

  • The preview reflects the intended version of the site, including the important page types and assets.
  • The agreed change survives the normal build or publishing process.
  • The affected customer journey works on mobile, including an understandable failure response.
  • The business can find the resulting test enquiry or record in its agreed destination.
  • The previous version can be restored using a documented method; changes to stored data have their own recovery plan where relevant.

This is a limited acceptance exercise, not a complete security or quality audit. Write down what it covered and what it did not. Ask the incoming developer to update the instructions wherever the rehearsal required undocumented knowledge.

Why a working homepage is insufficient

My own portfolio provides a concrete example. Its English and Hungarian pages are prepared during a build and served through an integration in the application. The contact form uses a separate server endpoint and email service. Reproducing the visible homepage alone would leave the enquiry flow unverified.

That is why I would ask someone taking over this site to demonstrate both a published-page change and the contact integration. The check follows the actual architecture rather than a generic promise that “the website opens”.

The same principle applies to the scope shown in my MarciCRM portfolio entry: property enquiries connect with calendars and follow-up. A receiving developer would need to investigate those connections, not just the screens. This describes the product's verified scope; it is not a claim that a particular supplier handover has been completed.

If the enquiry journey already fails, treat that as a specific diagnosis. My guide to contact forms that report success without delivering an email explains how to isolate that problem.

Check what an export actually preserves

The answer depends on the platform. A Webflow code export, for example, does not include a working CMS or ecommerce system, and its exported forms do not retain submission processing. Moving the files elsewhere can therefore require replacement services. That is different from another developer continuing work within the existing platform. Webflow's code-export documentation.

For WordPress, a database backup does not include themes, plugins, uploaded files or configuration files. The recovery material needs to cover the relevant files as well as the database. WordPress database-backup guidance.

Ask the supplier to explain the limits of your actual export and demonstrate the intended restoration or continuation route. Do not judge completeness by the size of a ZIP file. Equally, a platform dependency is not automatically a reason to rebuild: it may be acceptable if the business can keep operating and making the changes it needs.

Review access as part of the transition

An account transfer is not necessarily a clean break in permissions. GitHub documents that existing collaborator access can remain on a transferred repository and that associated webhooks, secrets and deploy keys remain attached. Review the resulting access and integrations instead of assuming the transfer removed them. GitHub repository-transfer documentation.

Keep secret values out of handover notes. Record their purpose, secure storage location and responsible administrator. Limit access to what each person needs, and plan credential changes with the services that depend on them; OWASP recommends both least privilege and documenting rotation dependencies. OWASP's secrets-management guidance.

For an ordinary planned handover, agree when the outgoing supplier's access ends and who supports the transition. Avoid cancelling a service simply because its purpose is unclear: identify what relies on it first. Suspected compromise needs its own incident response, not this routine handover sequence.

Choose the next scope from the findings

I would ask for a conclusion in one of these forms:

  • Continue maintenance: the relevant rehearsal passed, access is established and the upcoming work fits the current system.
  • Repair before takeover: the system is usable, but a defined issue such as a broken build or undocumented integration must be resolved first.
  • Replace one component: a particular service blocks the required work, while the rest of the website can remain.
  • Investigate a rebuild: the assessment identifies concrete limitations and compares the cost of keeping the system with replacing it. “I prefer another framework” is not enough evidence by itself.

Include unresolved questions, the evidence behind the recommendation, one-off work and recurring costs. Ask who handles incidents and future updates. A fixed maintenance price that silently assumes away an unknown deployment process is not yet a comparable proposal.

If URLs must change, add a separate migration plan. Google calls for mapping old addresses to new ones, redirects and monitoring, and warns that rankings can fluctuate during a move. Do not bundle that into a supplier change without an explicit reason and scope. Google's site-move guidance.

What to send before asking for a takeover quote

Send the public website address, the reason for changing developers, the next change you need, the platform if known and a non-secret list of available access. Mention important integrations, deadlines and anything the current supplier has already handed over. Leave unknown items marked as unknown.

Contact me about your existing website at hello@davidbuka.com. We can start by defining the checks needed to decide whether to maintain, repair or replace it. You do not need to send passwords or customer records with the first enquiry.

Sources checked on 28 October 2026. The suggested rehearsal is an example assessment, not a reported client outcome. The cover is an original editorial illustration.