How to Manage Code, Access and Hosting Handover When Changing Your Website Service Provider?

Which Digital Assets Should Be Identified Before Migration?

The first step in changing providers is to create a single inventory of all digital assets and access credentials required for the website to operate. Obtaining only the source code or hosting account may not be sufficient; the domain, database, DNS, email, CMS, analytics tools, CDN, SSL, licenses and external services may all be parts of the same system.

Why is a technical inventory the foundation of the handover?

For each asset, record where it is located, who owns the account, who has administrator access and how it can be transferred to the new provider. This approach turns the criteria for changing a web design company into a concrete inventory of technical assets. It is particularly important to distinguish services held under the former provider's accounts from services held directly in accounts controlled by the customer.

• Domain registration and DNS management account
• Hosting, server, CDN and SSL access
• Source code, repository and deployment files
• Database and current backups
• CMS administrator and technical user accounts
• Email and third-party service connections

“Plans are worthless, but planning is everything.” - Dwight D. Eisenhower

How Should Source Code and Usage Rights Be Reviewed?

When evaluating a website code handover, delivery of source files should be distinguished from the rights to use, modify and further develop that code. Having access to the files alone does not necessarily mean that all intellectual or contractual rights have transferred to the customer; applicable agreements and license terms should be reviewed separately.

Are contractual rights and technical delivery the same thing?

No. Technical delivery may include repositories, source files, database structures, configuration examples and required documentation. Contractual rights determine how those materials may be used. Therefore, the provisions that should be included in a contract with a web design company should be evaluated together with the actual technical handover. Licenses for third-party themes, plugins, fonts, APIs or software libraries should also be reviewed separately.

• Verify the scope of source code delivery
• Check whether repository access can be transferred
• Review usage and modification rights in the contract
• Evaluate third-party licenses separately
• Distinguish custom development from licensed components
• Identify missing technical documentation before migration

How Should Domain and Hosting Access Be Managed?

The management model for domain and hosting access directly affects continuity when changing providers. Where practical, keeping critical digital assets in accounts controlled by the customer reduces dependency during future provider changes and makes authorization management more transparent.

How should account ownership and technical management be separated?

The domain can remain in the customer's account while DNS or server administration is delegated to the technical provider. Likewise, ownership of the hosting account and day-to-day system administration do not have to belong to the same party. Understanding how cloud and server management is structured makes it easier to determine which access level the new provider actually needs. The important point is to define the account owner, billing responsibility and technical administrator clearly.

• Verify who owns the domain account
• Record registrar and DNS access separately
• Determine whose name the hosting account is under
• Review server administrator access
• Document billing and renewal responsibilities
• Create a plan for removing former users

What Should the New Provider Review Before Migration?

Before submitting a migration proposal, the new provider should technically review the architecture and dependencies of the existing website. A reliable transition scope is difficult to define without understanding the programming language, framework, CMS, server versions, database, integrations, scheduled tasks, file storage method and security configuration.

Which risks does technical discovery make visible?

Technical discovery is not performed only to look for defects. It reveals whether the new team can maintain the existing system, which components can be migrated directly and which ones require reconfiguration. When assessing a web design company's technical competence, the questions a candidate provider asks, the review methods it uses and the way it classifies migration risks can provide useful evidence of its approach.

• Review application and framework versions
• Identify server requirements and dependencies
• Check database size and structure
• List APIs and third-party integrations
• Evaluate the security and access model
• Verify that backups can actually be restored

How Should a Website Migration Plan Be Phased?

A provider-change migration should be planned as more than copying files from one server to another. A sound website technical handover plan separates access collection, backup, target-environment preparation, data transfer, configuration, verification, DNS transition and post-migration observation into distinct steps.

When should the new environment go live?

The new environment should be tested before live traffic is directed to it whenever practical. For systems where data continues to change, the final synchronization method should also be planned. DNS changes, email records, SSL certificates, redirects and scheduled tasks should form part of the migration plan. This makes it clear which team performs each action during the transition and preserves a rollback option if an unexpected problem occurs.

• Create a current and verified backup
• Prepare the new hosting environment in advance
• Run the application in a test environment
• Define the data synchronization method
• Plan DNS and SSL transition steps
• Document the rollback scenario

Which Tasks Should a Hosting Migration Proposal Separate?

A hosting migration proposal should not present the entire project as a single generic “site migration” item. Technical discovery of the existing system, access collection, backup, target-environment setup, data migration, testing, DNS changes and post-migration support may represent different workloads. Separating them makes competing proposals easier to evaluate.

What scope should you look for when comparing proposals?

Two providers using the same service label may not be offering the same work. One proposal may cover only file and database transfer, while another may include performance checks, redirect verification, integration testing and a defined post-migration support scope. The criteria used to compare website proposals can also help clarify work packages and responsibilities in migration projects.

• Technical discovery and existing-system analysis
• Access collection and account verification
• Backup and restoration verification
• Hosting and application migration tasks
• DNS, SSL and redirect configuration
• Testing and post-migration technical support

Which Tests Should Be Completed After the Migration?

Website transition support should not be considered complete simply because the home page opens on the new server. Critical functions such as pages, forms, user sessions, administration panels, email delivery, API connections, redirects, file uploads and scheduled tasks should be tested systematically after migration.

Why should acceptance testing be included in the proposal?

When the testing scope is defined in advance, both the customer and the new provider know the conditions under which delivery is considered complete. Visual inspection alone is not sufficient for dynamic websites. CMS administrator access, database write operations, form notifications, integrations and security settings should be functionally verified. Where possible, issues introduced by the migration should also be distinguished from technical debt that already existed before the handover.

• Test critical pages and user flows
• Verify form submissions and email delivery
• Check CMS administrator operations
• Test APIs and third-party services
• Review redirects and SSL configuration
• Verify backups and scheduled tasks

How Should Responsibilities Be Defined During the Change?

In a successful website service provider change, responsibility boundaries should be as clear as the technical tasks themselves. The data the former provider must deliver, the accounts the customer must provide, the checks the new provider will perform and the support available after migration should be documented in a responsibility list.

What type of handover plan should you request from a new provider?

You can ask candidate providers for a practical plan covering the access inventory, technical assessment scope, migration sequence, testing criteria, responsible parties and post-migration support approach. A well-defined handover scope helps you evaluate not only a provider's ability to build a new website but also its approach to taking over an existing system in a controlled manner. Instead of accepting a vague “migration included” statement, clarify which task will be completed by whom and against which acceptance criteria.

• Define the former provider's delivery responsibilities
• List the access credentials the customer must provide
• Define the new provider's technical responsibilities
• Document testing and acceptance criteria
• Clarify the post-migration support scope
• Plan access removal and project closure steps