Taking over a website built by another agency: what responsible support onboarding should cover

A new support agency can receive an administrator login in minutes. It cannot responsibly understand an established website in minutes.

The visible pages may depend on custom code, extensions, scheduled jobs, hosting configuration, DNS, APIs, vendor licences, data imports, campaign scripts and manual operational steps. Documentation may be incomplete. Ownership may sit in former staff or supplier accounts. An apparently small change can affect a business rule nobody has described.

That does not mean a new partner should rebuild the website or run a maximum-depth audit before helping. It means the partner should establish enough evidence and control for the level of responsibility it is being asked to accept.

Responsible onboarding converts an inherited website from an unknown dependency into a governed support environment.

The short answer: seven onboarding outcomes

Fit, urgency and business criticality are understood.
Client ownership and authorised access are confirmed.
A proportionate technical baseline is captured.
Providers, systems and dependencies are mapped.
Immediate risk and continuity issues are triaged.
Support boundaries, priorities and communication are agreed.
A prioritised maintenance and improvement roadmap is established.

Onboarding depth should match complexity, evidence and risk.

An initial qualification meeting can identify the likely pathway. The technical review, access work, baseline, remediation plan and operating model form part of an agreed engagement.

Start by defining what "support" means

The client and agency may use the same word for different services.

Clarify whether the requirement is:

Routine CMS and dependency maintenance
Responsive fault triage
Content and campaign changes
Development and enhancements
Performance or conversion improvement
Integration support
Release coordination
Strategic roadmap and governance
Reserved capacity and service levels
Flexible, non-urgent project work

Hosting infrastructure is a separate layer. Emote does not sell, resell or directly provide it. Emote can advise on requirements, coordinate with an appropriate hosting partner or work with the client’s suitable existing provider. The client normally contracts with and pays the host directly.

A support proposal should name inclusions, exclusions, intake, priority, response basis, approvals and third-party coordination. It should not imply guaranteed resolution for every unknown issue.

1. Qualify business criticality and immediate urgency

Before reviewing technology, understand the website’s business role.

Does it process sales, bookings or applications?
Does it support customer, member or trade access?
Are forms operationally critical?
Which integrations must keep running?
What data does it collect or expose?
What happens if the site or one journey fails?
Is there an active incident, end-of-life deadline or campaign?
Which internal teams and suppliers depend on it?

This determines onboarding depth and order. A low-change brochure site and a transaction platform should not receive the same transition programme.

Urgency also needs classification. A confirmed checkout failure differs from a request to refresh a landing page. Stabilise genuine incidents first, but do not allow every inherited backlog item to become an emergency.

2. Confirm ownership before accepting access

The organisation should control its digital assets wherever practicable.

Review:

Domain and registrar
DNS service
Hosting-provider account
CDN and certificate services
CMS and super-administrator accounts
Code repository and organisation
Deployment platform and secrets
Analytics, tag manager and consent tools
Search Console and merchant services
Email-delivery and form services
Integration and API accounts
Extension, theme and font licences
Media and data rights

Do not solve ownership by creating another shared password. Use named accounts, appropriate permissions, multifactor authentication and a documented recovery path.

The Australian Cyber Security Centre notes that privileged accounts can alter or circumvent controls and are attractive targets. Its personnel-security guidance supports restricting privileged access to what duties require.

When an outgoing agency cooperates, request an asset register and transfer plan. When it does not, recover control through the client’s legal, account and provider relationships rather than attempting unauthorised access.

Control is more than knowing a password.

3. Capture a proportionate technical baseline

The new partner needs to understand enough of the environment to make safe changes.

The baseline may cover:

CMS, framework, runtime and versions
Themes, extensions and dependencies
Custom code and configuration
Repository history and branching
Development, staging and production environments
Deployment and rollback process
Backups and restoration responsibility
Scheduled tasks and background jobs
Forms, search and priority journeys
Errors, logs and monitoring
Performance and accessibility indicators
Data stores and retention
Known security advisories
Documentation and outstanding defects

Depth should follow risk. A diagnostic scan cannot prove security, and an automated score cannot explain every architectural issue. Record the method, date, access limits and evidence confidence.

WordPress’s Site Health documentation shows the type of environment and configuration information one platform exposes, but it is only one input. A complete inherited website may include services far outside the CMS.

Avoid making a consequential production change until the team understands the release and recovery path. If no usable staging environment, repository or backup evidence exists, stabilising those controls may be the first priority.

4. Map systems, providers and manual steps

List every dependency and its owner:

Hosting and infrastructure provider
Domain and DNS provider
CMS and extension vendors
CRM, ERP, PIM and inventory
Payment, shipping and tax
Booking and authentication
Search and mapping
Email, SMS and notification
Analytics, advertising and consent
Security and monitoring
Content feeds and data imports

For integrations, record the data exchanged, source of truth, frequency, authentication, failure behaviour, alerts and support contact.

Ask staff about manual steps. An administrator may upload a file every morning, reconcile failed orders or renew a licence from a personal account. Those operational dependencies rarely appear in architecture diagrams.

The Australian Cyber Security Centre’s guidance for boards describes cyber supply-chain risk across the design, delivery, maintenance and disposal lifecycle. An agency takeover is a useful moment to make provider dependencies visible, not to claim the new agency controls every one.

5. Separate defects, risks, debt and opportunities

An inherited backlog often mixes four categories:

Active defect

Specified functionality is not working as intended. Confirm impact, reproducibility and current contractual responsibility.

Operational risk

Examples include lost access, absent recovery evidence, unsupported components, unmonitored integration failure or unclear ownership.

Technical debt

The website works, but prior decisions make change, maintenance or risk management harder. Article 34 provides a deeper framework.

Improvement opportunity

The site could create more value through UX, content, performance, search, accessibility or new capability.

Do not treat every inherited issue as a defect the new agency should absorb. Classify it, identify evidence and obtain approval for the appropriate work.

6. Triage before building a roadmap

Prioritise by consequence and dependency rather than stakeholder volume.

A useful sequence is:

Restore active critical service.
Secure client control and recovery.
Address exposed high-consequence risk.
Stabilise deployment, environments and integration visibility.
Complete essential maintenance.
Resolve priority user and commercial friction.
Plan deeper technical debt and improvement.

Use a risk statement: condition, plausible event, business consequence and current evidence. "Plugin is old" is a condition. "An internet-facing unsupported extension with a relevant known vulnerability could allow unauthorised access to customer data" is a risk statement that still needs evidence and appropriate security expertise.

The Australian Cyber Security Centre’s patching guidance recommends timeframes proportionate to exposure and vulnerability. Updating inherited software may require compatibility testing and rollback, not an indiscriminate bulk action.

7. Agree the operating model

Onboarding should finish with clear continuing responsibility.

Define:

Service owner and client decision-maker
Support intake channel
Priority definitions
Response and communication basis
Hours or coverage window
Planned maintenance process
Release and acceptance process
Third-party escalation
Emergency authority
Change approval and budget
Reporting and roadmap review
Exit and knowledge transfer

Response is not the same as resolution. A new agency may acknowledge and triage an issue but depend on reproduction, access, a vendor or a safe release window before correcting it.

Choose a support arrangement that matches criticality and demand. Occasional, non-urgent work may suit flexible capacity. Business-critical platforms may need reserved capacity, agreed service levels and proactive governance. Current Emote commercial rules must come from the current proposal and Master, not this article.

Preserve search and measurement continuity

A takeover can quietly lose evidence if analytics, tags, consent, Search Console, advertising pixels or conversion events remain in supplier-controlled accounts.

Confirm:

Client-controlled properties and administrators
Current measurement plan
Priority conversions
Tag ownership and publishing rights
Consent configuration
Data retention and access
Search Console verification
XML sitemaps and robots controls
Redirect and canonical rules
Reporting dependencies

Do not rebuild tracking blindly. Understand the existing definitions and business use, then correct what is unreliable through an agreed measurement scope.

Plan the outgoing-agency handover professionally

Where possible, request:

Current architecture and asset register
Repository and deployment instructions
Environment and provider contacts
Data model and integration documentation
Known issues and backlog
Release and rollback process
Licence and renewal list
Backup and restoration information
Support history and incident patterns
Current access list
Scheduled work and change freezes

Keep the transition factual. The objective is continuity, not blame. The outgoing team may hold valuable context even when the relationship is ending.

The new agency should document what was received, what could not be verified and what assumptions remain. Lack of documentation is an operational fact, not proof of poor workmanship.

Public Emote example: audit, prioritise, improve, maintain

Emote’s public Bastion Lane Espresso case study describes three audits across design, SEO and technical performance, followed by a priority schedule. The work improved shop and product-listing experiences, added customised plugin rules for a complimentary checkout product and continued into plugin maintenance.

The public page reports directional changes without a quantified comparison period, so it should not support a numerical return claim. It demonstrates a responsible pattern for inherited improvement: understand several dimensions, prioritise, implement and maintain.

Evidence and priority should precede inherited change.

Define when onboarding is complete

Onboarding should end with evidence and decisions, not merely the expiry of a setup period.

A completion record can confirm:

Which assets and accounts are under client control
Which environments and release paths were verified
Which systems and providers were mapped
Which urgent risks were corrected, accepted or escalated
Which areas could not be assessed and why
Which maintenance and support boundaries now apply
Which backlog items have evidence, priority and an owner
Which documentation and access records were created

The record protects both parties from false assumptions. It does not certify that an inherited website has no undiscovered defect or security issue. It states what was examined, to what depth and with what limitations.

Schedule a later review after the new team has observed real releases and incidents. Some operational dependencies only become visible through use. Update the baseline when evidence changes rather than treating onboarding as a one-time guarantee.

Use the first safe change to verify the operating model

Documents and access checks cannot prove the whole support system. After the baseline is established, choose a low-risk but representative change that exercises the way the parties will actually work.

The change should be meaningful enough to test:

Request intake and priority
Scope and approval
Repository and environment access
Backup or rollback preparation
Development and peer review
Staging and client acceptance
Deployment authority
Production verification
Communication and documentation

A content-only correction may be too narrow if continuing support will include code, integrations or releases. A critical checkout, authentication or infrastructure change is too consequential for an unproven first deployment unless immediate risk leaves no safer option. Choose a bounded component or configuration change with clear acceptance and a practical recovery path.

Before work begins, record the expected behaviour, affected systems, known dependencies and person authorised to approve release. Confirm that the code and production state can be reconciled. An inherited repository may not contain every live change, and an apparently routine deployment can overwrite undocumented work.

During delivery, capture evidence rather than relying on confidence. Did staging reflect production closely enough? Did automated and manual checks cover the affected journey? Could the team access logs and provider support? Did the client know when acceptance was required? Was production verification completed by a named owner?

After release, hold a short review. Record where the operating model worked, where access or documentation failed and which controls must change before higher-risk work. Update the control register, deployment notes and backlog. If the first change reveals material uncertainty, narrow the support boundary or complete deeper assessment before accepting broader responsibility.

The goal is not to make a small task ceremonious. It is to validate that the new support relationship can move a change from request to verified production safely. That evidence is more useful than a handover meeting that ends with every participant assuming someone else controls the critical step.

Questions to ask a prospective support partner

Can you support the current platform and integrations?
What information is required before you accept responsibility?
What is included in qualification, onboarding and continuing service?
How will ownership and access be handled?
How will you assess an inherited codebase proportionately?
What happens if immediate risk or undocumented complexity is found?
How are support requests prioritised?
How do you separate response from resolution?
How are third-party providers coordinated?
What maintenance and release controls are used?
How are hours, approvals and change managed?
What documentation and exit support will the client receive?

Preserve evidence before changing access

Before credentials, DNS, deployment or plugins are changed, capture ownership, versions, backups, active integrations, scheduled jobs and known incidents. The baseline protects continuity and makes later decisions auditable.

Frequently asked questions

Can Emote support a website it did not build?

Potentially, yes. Fit depends on platform, complexity, condition, access, risk and required service. An agreed onboarding review establishes the appropriate pathway before ongoing commitments are made.

Is support onboarding a free audit?

The initial qualification conversation is not a technical audit. Any access recovery, technical review, risk assessment, remediation planning or operating-model setup is scoped separately in an agreed engagement.

Must the outgoing agency participate?

Cooperation is helpful but not always possible. Client ownership, provider relationships and available evidence may allow transition. Missing access or authority can remain a blocker.

Will the new agency need to rebuild the website?

Not automatically. The goal is to support and improve a serviceable asset where credible. Rebuild becomes relevant only when underlying constraints or risk make continued support disproportionate.

Who should own the domain and provider accounts?

The client should normally control business-critical accounts with named administrators and recovery arrangements, while suppliers receive the least access needed for their role.

Does the support agency become the host?

Not in Emote’s model. Emote does not provide hosting infrastructure. It coordinates with the client’s appropriate provider or can recommend a suitable partner.

How Emote can help

The first goal of a support takeover is not to change everything. It is to know what the organisation owns, how the website works, which risks matter and how future change will be controlled.

That evidence allows the new partner to recommend the smallest credible programme: stabilisation, maintenance, flexible support, retained support, optimisation, redesign or rebuild.

If you are considering a new website support partner, book an initial meeting with Emote. We will clarify the platform, immediate need and known constraints, then recommend an appropriate onboarding and support pathway. Detailed review and remediation commence only under an agreed engagement.