Website Handover Checklist Malta: What To Receive

A website is not fully delivered simply because it is visible online. The business should be able to identify who owns the domain, access the hosting and WordPress installation, understand how leads are captured, retrieve current backups and manage the services connected to the site.

This website handover checklist for Malta businesses covers the information, access and evidence that should be transferred at launch or when changing developer. It complements the project scope and acceptance testing, but focuses specifically on operational control after the build is complete.

Contents hide

1 1. Start with a complete asset register

2 2. Confirm domain ownership and renewal control

3 3. Transfer hosting access and technical contacts

4 4. Create business-controlled WordPress administrator access

5 5. Document the theme, plugins and licences

6 6. Identify custom code and source files

7 7. Receive a usable backup and restoration explanation

8 8. Transfer analytics, tag and search access

9 9. Map forms, enquiries and integrations

10 10. Record email and DNS dependencies

11 11. Confirm privacy, consent and data handling

12 12. Complete launch acceptance tests

13 13. Provide content and maintenance training

14 14. Finish with an access review

15 Website handover checklist

16 Plan the handover before development begins

17 Official resources

1. Start with a complete asset register

Ask the developer to provide one list of every service used by the website. The list should include the service name, purpose, owner, renewal arrangement, primary business contact and access method.

Domain registrar and DNS provider
Web host and server plan
WordPress administrator account
Theme, child theme and page builder
Premium plugins and licence owners
Email delivery or SMTP service
Form, booking, payment and CRM integrations
Analytics, tag management and Search Console
Cookie-consent and security services
Backup, uptime and performance tools

A simple register prevents hidden dependencies from appearing only when a licence expires, a staff member leaves or the site needs urgent repair.

2. Confirm domain ownership and renewal control

The domain should be registered in the correct business or owner name, using an email address the organisation controls. Confirm the registrar, renewal date, payment method, administrative contact and recovery method. Enable two-factor authentication where available.

The business does not necessarily need to move the domain at handover, but it should be able to access and manage it. ICANN explains that registrants have rights to information about managing, renewing and transferring their domain. For applicable generic domains, an authorisation code is used to help identify the domain holder during a registrar transfer.

Do not publish transfer codes or store them in a shared project document. Record how an authorised person can obtain one when needed.

3. Transfer hosting access and technical contacts

Record the hosting company, plan, renewal cycle, server location if relevant, support route and account owner. The business should know whether the developer’s agency account hosts multiple clients and what happens if the relationship ends.

Ask for access appropriate to the hosting arrangement, together with any control-panel, SFTP, database or deployment details needed by an authorised replacement developer. Credentials should be transferred securely rather than placed in ordinary email or a public document.

4. Create business-controlled WordPress administrator access

The organisation should have its own named WordPress administrator account. Avoid relying on a generic account owned by the developer. Confirm that the business administrator can sign in, reset the password and manage users before the project is closed.

Keep daily editors at the lowest role that supports their work. WordPress roles provide different capabilities, so not everyone who changes content needs full administrator privileges. Remove unused test accounts and document any service accounts that must remain.

5. Document the theme, plugins and licences

List the active theme, child theme, page builder and every plugin that performs a material function. For paid products, record:

Who owns the licence
Which email or vendor account controls it
The renewal date and current renewal responsibility
What stops working if the licence ends
Whether the licence can be transferred

A premium licence may continue to power the existing site while access to updates or support stops. The precise behaviour depends on the product, so the handover should not make assumptions.

6. Identify custom code and source files

Ask where custom functionality is stored. It may be in a child theme, custom plugin, code-snippet manager, tag manager or an external service. Obtain the current source files and enough documentation for another competent developer to understand the purpose and dependencies.

Record any repository, deployment workflow, build process, environment variables and third-party API configuration. Secret keys should be transferred through a secure channel and rotated when appropriate. Do not place live secrets in the general handover document.

7. Receive a usable backup and restoration explanation

A handover backup should cover the database, uploads, themes, plugins and relevant configuration. Record where backups are stored, how often they run, how long they are retained and who receives failure notifications.

Ask for evidence that restoration has been tested in an appropriate environment. A backup that has never been restored provides less assurance than a documented recovery test. WordPress also provides an XML export for content, but that export is not a complete replacement for a full site backup because it does not by itself reproduce the entire installation.

8. Transfer analytics, tag and search access

The business should control its measurement properties rather than receiving screenshots from an agency-owned account. Confirm access to Google Analytics, Google Tag Manager or other tag tools, and Google Search Console.

Google Analytics allows users to be added at account or property level with specific roles. Google Search Console distinguishes owners and users, with owners having full control. Ensure the business has appropriate administrator or verified-owner access before removing the outgoing developer.

Record measurement IDs, conversion definitions, connected advertising accounts and any consent-dependent tag behaviour. Test that forms, calls, purchases or bookings still produce the intended events after launch.

9. Map forms, enquiries and integrations

For every form, booking widget or checkout, document where the submission goes and what happens next. Include recipient addresses, CRM destinations, automated replies, spam controls and stored data.

Submit a live test from desktop and mobile.
Confirm that the user sees a genuine success message.
Check delivery to the correct person or system.
Verify that tracking does not count failed submissions.
Document how stored submissions are reviewed and deleted.

Do not close the project with placeholder addresses, developer-owned API connections or test payment settings still active.

10. Record email and DNS dependencies

A website launch can affect email if DNS records are changed incorrectly. The handover should identify the provider responsible for business email and record the purpose of relevant DNS entries without exposing confidential information.

If the website uses an SMTP or transactional email service, confirm who owns the account, which sender domains are verified, how failed delivery is monitored and whether renewal charges apply. Send test messages to more than one provider where practical.

11. Confirm privacy, consent and data handling

List the cookies, embedded services, tracking tools and forms in use. Confirm who supplied the privacy and cookie wording, who approved it and who is responsible for future updates. Technical implementation should match the organisation’s approved privacy position.

Document where personal data is stored, which suppliers can access it, retention settings and the process for responding to access or deletion requests. Seek appropriate legal or privacy advice for the organisation’s circumstances.

12. Complete launch acceptance tests

The handover should include a dated acceptance record. Test the agreed browsers and devices, navigation, forms, search, downloads, payments, account functions, redirects, error pages, accessibility basics and performance-sensitive pages.

Record known limitations separately from defects that must be corrected. Confirm the warranty or post-launch support period, what it covers, how issues are reported and the expected response route.

13. Provide content and maintenance training

Training should reflect the tasks staff will actually perform. Demonstrate how to edit pages safely, publish posts, replace images, review enquiries and avoid damaging reusable layouts. Provide short written or recorded instructions for recurring tasks.

Then assign ongoing responsibilities for updates, backups, security monitoring, form tests, uptime and content review. Our separate website maintenance checklist can be used to build that routine.

14. Finish with an access review

Once the handover is confirmed, review all users across WordPress, hosting, the registrar, analytics, Search Console, tag management, form tools and connected services. Remove obsolete access, rotate shared credentials and confirm that at least two authorised business contacts can recover critical accounts.