The problem

A financial services business wanted its main website to drive more sign-ups to its online platform, but the site was hard to change.

It ran on WordPress, managed by an outside consultant who held the only access to the code and database. There was no staging site and no reliable backups, so every change went straight to live.

What was done

  1. Got agreement first. The plan to move the site into the company's own AWS environment was proposed to the CEO and signed off.
  2. Worked with the consultant. The code, database, credentials and settings were handed over smoothly and on good terms.
  3. Built the new home. The hosting was set up on AWS, with a database, Elastic Beanstalk, version control and a deployment pipeline.
  4. Brought everything up to date. WordPress, PHP and the plugins were upgraded, and security was tightened.
  5. Moved the site. The code and database were migrated, with regular backups and a separate staging site set up.

The result

The migration went live without issues. The business owned its code and data, could make changes itself, and had a safer, up-to-date site with backups and staging.

Check where you stand

You can answer most of these without any technical knowledge:

  • Who controls your domain name, and is it in your company's name?
  • Could you get a full copy of your website and database today?
  • When was the last backup, and has anyone tested restoring it?
  • Can changes be tried somewhere other than the live site?
  • If your supplier disappeared tomorrow, could someone else take over?

If any answer is "I don't know", it's worth finding out. This isn't about distrusting your supplier. A good supplier should be comfortable with you holding your own keys.

This article draws on work by Syed Quadri, SMART5's director, while working at another organisation. It wasn't a SMART5 client project, so the organisation isn't named.