Every few years, being forced by procurement or due to deteriorating relationships, clients will need to change digital agencies to support their websites, apps or portals. Handing over the key to your digital kingdom can be a daunting task and it is actually very risky. It’s very different than a standard website revamp where we can pretty much discard the old platform and build from new.
In my previous article, I covered the key elements of a thorough procurement process for selecting the right digital partner. Following these steps and recommendations should mean you selected the right partner, but what happens next?
With my team at Cyber-Duck, I have had a particularly busy few years taking over a lot of existing platforms, from online educational portals to website CMS and eCommerce stores. I have learnt how to plan and execute successful migration in a matter of weeks. Based on these experiences, here is my 7-step guide sprinkled with tips on the critical elements of the handover process from your incumbent agency to your new digital partner.
1. Ensure you have access to all systems
I have seen horror stories about companies not in control of their branded domain name and agencies forgetting to renew it, taking the platform offline! For simplicity, agencies sometimes bundle all their clients’ domains in one place, under the same account. This makes it more difficult to transfer one of those out, involving unnecessary costs and time.
Similarly with the hosting server, your site or platform might be hosted on a shared space which makes it impossible to give you access to your site’s source without sharing other clients’ data. The risk is that if the site goes down, or the agency goes bust, you have no way of recovering the site and bringing it back online without the original source code.
The main point is that you need to be in control of the access rights, control who has access to your assets and tools. You also need to be able to cut someone off if the trust or contractual relationship ends.
So before thinking about switching agency, please double-check that you have admin access to:
- Your domain name registrar and DNS settings;
- The “master” admin to your Content Management System;
- The hosting server where your platform/site and database are stored, and the contact details of the associated provider if you need to make changes;
- The repository of your source code, as well as media including images, documents and videos that make up the site's content;
- The 3rd party libraries or licences for fonts, forms, widgets;
- The login to your social media accounts and online tools (CRM, analytics dashboard, marketing automation platform…).
Some agencies might get suspicious about sharing all of those. But even if you are not planning on moving away, it is best practice for due diligence and business continuity to have your own copy/backups. Access to core systems and logs might be required for compliance and legal reasons too. After all, it’s all your intellectual property you already paid for!
2. Handover meeting
Ideally, after years of collaboration, you would have built and kept a good relationship with the incumbent agency. When it’s time to make the introductions to the new provider, it’s best to organise a 3-way call with the following agenda:
- Background of the project and team (round table intros);
- Quick review of all systems at play - highlighting any custom config or non-standard implementation;
- Current status of releases (any work-in-progress?);
- High level migration plan with cut-off dates, code freeze periods.
The new agency needs to drive the migration plan on their own terms, following their tried and tested process. It is up to the new agency to build the plan with the order of tasks they need, clear responsibilities and dates. It needs to be project managed with direct point of contact (and escalation channels) in your company as well as with the previous partner.
If the relationship had deteriorated or the agency is no longer trading, it might get trickier to organise. In this case, it’s even more important to pick a new supplier that is already “expert” in the technology, language or platform. There won’t be any chance to “learn on the go” and you’ll need specialists’ expertise to fix any issues or improve on what might be an out-dated platform.
3. Prepare the assets
After gathering access to the systems, the new agency will also need to take over the other project assets. You should gather all the relevant materials that can help onboard the new agency, give background information. These usually include:
- Your branding guideline and current assets;
- A stakeholder list with roles and responsibilities in your team;
- User and persona research about your audience, ICP and target customers;
- Your marketing plan with KPI and activities;
- The backlog of features and existing bug list for your product;
- Your internal policies and requirements around InfoSec, data protection and quality management.
To save time and budget on the induction and onboarding, you should organise a workshop with the new agency to present all of those and highlight the key findings or elements in each one. Share as much knowledge as you can so the new agency becomes a true extension of your team: with better data and insights, better recommendations will be generated!
4. Transfer access
Once you have the contract in place with the new agency, you can invite their team members to all the systems we listed on the first point. This is needed to reconfigure some of the settings, such as your new hosting account or change the API keys to discard previous access.
Remember to follow best practices and try to use named accounts, so you know who’s who for future audit, as well as capturing logs of who changes what!
5. Platform audit by the new agency
After the briefing session from point 3 above, the new agency will probably insist on spending a few billable days with the new platform. It usually means restoring the code and assets locally on their environment to run a code and features audit. We usually look for documentation, automated tests, custom modules, 3rd-party tool connections and overall structure and security of the elements. We compile a list of questions and recommendations to present that are usually added to your backlog to be prioritised.
At this stage, we will also upgrade some components and add tools from our internal stack. This includes monitoring agents for uptime or an automated deployment process for better reliability and velocity.
Monitoring wise, a lot of websites/platforms that we take over do not have proper error logging in place, which leaves us blind to the errors raised in the legacy code. We ask clients to create new Sentry accounts and analyse the first few days of activity to surface important issues that might not have been visible before.
The riskier part of this whole switching business is the lack of automated tests. Too many systems we take over do not have test suites and without knowing all the intricacy and dependencies of your platform, who can guarantee that a small change will not break something else in your website? On a recent project, we recommended spending 1 week just defining a testing plan and how to run regression - it took several days just adding tests for the critical components of the application (based on complexity or where issues may occur). This gave everyone better re-assurance that we won’t break them when adding future improvements.
6. Run a test deployment
Once everything is running smoothly locally, the new agency will be in a position to make deploy your application on the hosting server. Following the creation of a “deployment runbook” and tests to a staging setup for the preview site, we also enforce a production deployment of a minor change with minimal risk (i.e. copy edit). You should also request a “roll-back simulation” of the code and database to test the process of reverting a change if you detect something went wrong.
Whether it remains on the existing hosting environment or is transferred to a new one, this step is critical to confirm that all access and processes are in place before the official switch-over.
7. Time for the official switch-over
If all is stable, the new agency will confirm they are ready to take full ownership of your platform. At this point, you can give official notice to your existing supplier and turn off their access. Planning for the worst-case scenario, we’d recommend you keep them on standby for 14 to 30 days just in case you have additional questions post-handover. The extra cost of paying both suppliers over a few weeks’ overlap is well worth the peace of mind it brings!
I hope this guide serves you well. If you are going through this process and need a sounding board to review the plan or de-risk any element of this transition, get in touch ;-)
