Sometimes it’s desirable – or necessary – to find a new agency to host, support and maintain your website.

As Drupal CMS specialists, IE Digital has taken over responsibility for several existing sites from an incumbent agency, for the likes of ISEAL Alliance (Drupal 6), the Institute of Food Science and Technology (IFST) and the St Vincent de Paul Society UK  (both Drupal 7 with CiviCRM integration).

When migrating a website from another supplier, we follow the steps outlined below to ensure that everything goes as smoothly as it can.

1. Knowledge gathering and management

It’s really important to make sure your new supplier has a good understanding of both the technical details (e.g. server requirements, quirks with the system or scheduled jobs) and business processes (e.g. a yearly user registration process, regular mass mailing, or report generation). This allows the new supplier to make the correct technical and scheduling decisions throughout the migration process and beyond.

This knowledge gathering exercise will involve your new supplier liaising directly with the incumbent, and also asking you about your key business processes – so you’ll need to make sure everyone is available and willing to be open throughout this process. It’s important for the new supplier to document their findings for business continuity purposes and good knowledge management.

2. Create your migration schedule 

With lots of parties involved in a site migration, good communication is key. Regular updates and a clear migration schedule can help bring clarity to the process.

A plan should be created by the new supplier, with milestone timings agreed between all parties, such as the final switch over, the cut-off for adding/editing content, and website downtime. This will ensure all process dependencies and sign-off points can be met.

Always aim to have a brief ‘crossover’ period between the incumbent and the new supplier. This allows the two suppliers to communicate, ask questions, and troubleshoot any teething problems, so build this into your handover plan.

3. Build redundancy into the plan

Even with a great plan, chaos jumps at the chance of foiling good intentions, so make sure you plan for failure, too. There needs to be a process in place if everything goes awry. This can mean keeping the old copy of the website available for a short period of time after the migration is completed.

4. Manage data security

Changing hosts and suppliers will mean all of your website data will need to be exported and transferred to the new supplier. Ensure that the exported data is encrypted and transferred securely. The new supplier should confirm receipt of the export so that unnecessary copies of your data can be deleted.

5. Keep a reference copy

When problems with your website are discovered, there are always question marks over exactly how and when the bug was introduced. For this reason, it’s useful to create a working ‘snapshot’ of the website from when it is first transferred to the new supplier – this will act as a reference when identifying and troubleshooting possible legacy issues.

6. Perform a code audit and security updates

The new supplier should run a code audit on any custom code that has been written for the site. This will allow both the client and the supplier to identify any areas that could potentially be difficult or costly to maintain in the future. It’s important to update all modules and frameworks to the latest security releases as soon as responsibility for the site changes hands. This reduces the chance of the website being exploited and may include advantageous new features.

7. Acceptance test

Once the website has been migrated, the updates have been applied, and the new supplier has carried out internal testing, the client needs to ensure everything is working from their perspective and sign it off for launch. If any critical issues are found that require substantial investigation, this will increase downtime, so this is where you may need to put a reversion process into effect (see point 3).

8. Decommission the old server

In line with the migration plan, there should be a date agreed and sign-off process in place for the old website to be decommissioned. This should only happen once the newly hosted website is stable – it is good practice to have the old version privately available for a short period of time after the website is migrated.

As with any project, good planning and communication between all parties involved is the way to ensure success. By following the advice above, and choosing a new supplier with experience in migrating and supporting websites like yours, your migration should pretty much go without a hitch!