How Do You Transfer Source Code, Servers, and Analytics Accounts When Changing Web Development Partners?

What Should Be Checked First When Changing Web Development Firms?

The first check when changing web development firms is to identify who controls every digital asset and account required for the website to operate. A handover inventory should bring source code, database, server, domain, DNS, CDN, analytics, and third-party services into one list. This makes it possible to see which assets the new technical team needs to access, which permissions must be transferred into the company’s control, and where dependencies on the former provider exist before the transition begins.

Map the system first, then transfer access

A technical system map should be prepared before the end date of the relationship with the existing agency is finalized. Considering this together with the points covered in what to consider when changing web design companies makes it easier to plan not only the selection of a new provider but also the lossless transfer of the existing infrastructure. Instead of requesting every password on day one, the new team should determine which accounts belong to the company, which roles need to be created, and which services require reconfiguration.

• Add the source code repository and version history to the inventory.
• List server, cloud, CDN, domain, and DNS accounts.
• Identify database, file storage, and backup locations.
• Verify Analytics, Search Console, and Tag Manager access.
• Record email and third-party API services.

Any fool can write code that a computer can understand. Good programmers write code that humans can understand. - Martin Fowler

How Should Source Code and the Git Repository Be Transferred?

Source code handover should not be considered complete by simply sharing the latest project folder; where possible, the new team should receive controlled access to the Git repository, version history, branch structure, and relevant deployment configurations. Preserving version history makes it easier to understand when changes were made, trace problems backward, and continue the existing development process without losing context. If the company does not have repository ownership or administrator access, that issue should be clarified before the handover is finalized.

Verify that the code is runnable and transferable

After receiving the repository, the new company should be able to run the project in its own development or test environment and review dependency files, environment variables, build steps, and deployment requirements. It should also check whether passwords, API keys, or private access information have been embedded directly in the source code. Code handover is not only about file availability; the team should evaluate whether the project is understandable, whether documentation exists, and whether the repository actually matches the version currently running in production.

• Verify company-level administrator or owner access to the Git repository.
• Identify which commit or release is running in production.
• Confirm that dependency and build files are complete.
• Check whether secrets are stored directly in the codebase.
• Request documentation for installation and deployment steps.

In What Order Should Server and DNS Handover Be Managed?

Server and DNS handover should proceed by securing access and backups first, allowing the new team to review the current configuration second, and making changes only after verification. Treating a DNS change as the beginning of the transition is risky; infrastructure changes made before understanding the application, database, SSL, CDN, cron jobs, storage, and email dependencies can cause downtime or loss of functionality.

Document how the infrastructure works before moving it

The new provider should review the current resources, services, and access model covered by cloud and server management. The domain registrar account and DNS provider may not be the same service, while CDN, SSL, or email records may also be managed on separate platforms. Before the transition, copies of DNS records, server configuration, and critical scheduled jobs should be taken, and the team should determine which previous configuration will be retained as part of the rollback plan.

• Verify domain ownership and DNS management access separately.
• Create authorized company users in the server or cloud account.
• Document SSL, CDN, cron, and storage dependencies.
• Save a copy of current DNS records before the transition.
• Prepare a rollback scenario before making infrastructure changes.

How Should Databases and Backups Be Checked Before Handover?

Databases and backups should be checked for currency, integrity, restorability, and access permissions before handover. The existence of a backup alone is not enough; the team needs to know which database is used in production, where uploaded files are stored, and whether the latest backup can actually be restored. If content, customer records, form submissions, or application transactions change continuously, a final backup close to the transition time should also be planned.

Consider the file system and database within one recovery plan

During a website handover, the database dump and persistent files such as media or user uploads may exist in different locations. The new team should restore them in a test environment to confirm that the data opens correctly with the application. Moving backups away from an account controlled only by the former agency into a secure location that the company can access or manage jointly with the new provider helps preserve operational continuity after the provider change.

• Verify the production database and its version.
• Identify where media and user files are stored.
• Plan a current full backup before the transition.
• Restore the backup in a test environment to confirm usability.
• Make sure the company also has access to backups.

How Should Analytics and Search Console Ownership Be Transferred?

Analytics and Search Console ownership should be transferred by granting appropriate permissions to accounts controlled by the company rather than sharing the existing user’s password. Account ownership should be separated from personal access; Google Analytics, Search Console, Tag Manager, and similar measurement tools should include at least one company-controlled user with management access, while the new agency should receive only the level of permission needed to perform its work. This preserves historical data, configuration, and measurement continuity even when providers change.

Do not evaluate measurement accounts only by whether you can log in

The new team should review conversion definitions, event structures, tags, filters, and relevant site verifications in addition to property and container access. If critical configurations depend on the former agency’s personal account, a controlled transfer into a company account should be planned. This is important so the new provider can understand historical reporting and avoid data gaps after the handover; taking screenshots or configuration records of current settings before changing permissions can also provide a useful comparison point.

• Verify authorized Analytics users controlled by the company.
• Review Search Console ownership and user roles.
• Check Tag Manager account and container permissions separately.
• Record conversion, event, and tag configurations.
• Remove the former provider’s access after the new team has verified the setup.

Which Technical Audits Should the New Provider Perform First?

Before making changes, the new provider should perform a technical audit covering code health, security, performance, dependencies, infrastructure, and third-party integrations. The audit creates a baseline of the inherited system; it helps distinguish problems that already existed, risks that require immediate attention, and improvements that can be handled through planned development. Starting feature work without this review can allow hidden technical debt to combine with new changes and make later troubleshooting more difficult.

Turn audit findings into a prioritized transition plan

The criteria in technical audit and migration planning for an existing website provide a useful framework for ensuring that the new team does not evaluate the code simply as working or not working. From a security perspective, measures for corporate website security also support a fresh review of access, updates, and operational responsibilities. Audit findings should then be grouped into critical, short-term, and planned improvements.

• Review code standards, dependencies, and version status.
• Evaluate security vulnerabilities and access permissions separately.
• Check performance bottlenecks at application and infrastructure levels.
• Verify third-party API and service dependencies.
• Prioritize audit findings by risk and business impact.

How Should Third-Party Service and API Accounts Be Transferred?

Third-party service and API accounts should be transferred in a controlled way by identifying which business function each service supports and whose name the account is registered under. Email delivery, SMS, payments, maps, verification, storage, CDN, or other external services may form hidden dependencies within the application. Knowing an API key does not mean owning the account; billing, administrator access, quota management, domain verification, and key rotation rights should also be visible to the company.

Verify dependencies before immediately disabling old keys

The new team should first map which service key is used in which environment and for which feature. Where necessary, a new key can then be created in the company’s account, verified in a test environment, moved to production in a controlled way, and the old access disabled only after the system is confirmed to be working correctly. This approach reduces the risk that forms, notifications, payments, or integrations stop unexpectedly because a service held in the former agency’s personal or corporate account was terminated too quickly.

• List all third-party services together with their functions.
• Verify account ownership, billing, and administrator roles.
• Map which environment uses each API key.
• Test new keys in a non-production environment where possible.
• Disable old access only after the live system has been verified.

How Can Downtime Risk Be Reduced During a Website Transition?

Downtime risk during a website transition can be reduced by managing changes in stages with a backup, testing, rollback, and responsibility plan rather than making undocumented changes all at once. Creating a rollback point before critical changes preserves the option to return to the previous working state if the new configuration causes unexpected problems. Avoiding high-traffic or critical campaign periods and ensuring the technical teams are available during the same transition window can also reduce operational risk.

Approve testing and rollback scenarios before production changes

The new team should preferably run the application in a staging or similarly safe environment, test integrations, and verify required infrastructure settings before production changes. If a DNS or server change is necessary, the sequence, responsible people, and control checklist should be written in advance. After the transition, key pages, forms, sessions, integrations, analytics tags, and error logs should be checked. This goes beyond confirming that “the site opens” and verifies whether real business functions and measurement continuity have been preserved.

• Create a full backup and rollback point before the transition.
• Verify changes in a test environment where possible.
• Use an ordered checklist for DNS, server, and application steps.
• Test critical functions one by one after production cutover.
• Keep the previous infrastructure available until the new setup is verified.

How Can Continuity Be Secured with the New Web Maintenance Firm?

Continuity with the new web maintenance firm is secured by clearly defining access ownership, documentation, maintenance responsibilities, and change management in the contract after handover is complete. Dependence on the new provider should not be recreated; the company should retain management access to source code, domain, infrastructure, and analytics accounts, while ownership of assets and the handover process at contract termination should be defined from the start.

Use the audit as the basis for the maintenance and development proposal

After the technical audit, the new provider should plan urgent risks, maintenance requirements, and ongoing development work as separate items. Reviewing what a contract with a web design company should include can help clarify access, source code, support, handover, and responsibility boundaries. This turns the transition from a short process that simply removes the former agency’s access into a sustainable technical management model that also protects the company’s ability to change providers again in the future.

• Retain company administrator access throughout the contract.
• Separate maintenance, new development, and emergency response scopes.
• Define who is responsible for keeping documentation current.
• State source code and account handover terms clearly in the contract.
• Add regular backup, security, and performance checks to the operating plan.