Move One App First: Getting Your Business onto the Cloud Without the Chaos

The most common way a cloud move goes wrong is trying to move everything at once, against a deadline. Move one app, learn from it, then plan the rest with what you learned.

Why do big cloud moves go wrong?

Because they try to do too much, too soon. A Practical Guide to Cloud Migration, a 2021 book of essays by Google practitioners published by O'Reilly, names that as the most common failure in its opening chapter: too much, too soon, on a tight schedule. Nobody understands the new platform yet, things break, and the business gives up.

The book also tells the story of a company that, after landing a large contract, pushed the heart of its operation onto the cloud in six months. The developers made it work by teaching themselves in their free time and on weekends. Then more than three-quarters of them left, taking their new skills somewhere that treated them better.

In a small business, the same mistake looks like this. The office decides to move everything to the cloud over a long weekend. On Monday the billing software won't open, the shared drive is half-copied, and nobody knows which copy of a file is the real one.

The book's answer is simple: start with one thing, learn from it, and only then plan the rest.

How do you pick the first app?

Pick something low-risk that still matters; the book calls it strategic, low-hanging fruit. For a small business, a good first app passes five tests:

1. The business survives a bad day. If it is down for a day, customers still get served and staff still get paid.
2. It matters enough to notice. A success should save someone real time, so people trust the next move.
3. It stands mostly alone. Every connection to another system is one more thing to rewire and test.
4. Someone uses it daily. That person will tell you honestly, by lunchtime, whether the new version works.
5. You can check the result. You can compare old and new side by side and see that nothing is missing.

Good first candidates are one team's shared files, a staff booking or stock tool, or an internal wiki. Poor first candidates are billing, payroll, anything that takes payments, and the one system everything else depends on.

The first move also builds what every later move will reuse: the account, logins, backups and alerts. That groundwork is half the value of going first.

How do you move it with a way back?

Keep the old system running until the new one has proved itself. The safest move is boring, in six steps:

1. Write down what "working" means. List the five things people do with the app every day. That list is your test.
2. Back up the old system, and check that the backup actually opens. Our post on backups you have actually restored covers how.
3. Set up the new version alongside the old one. Switch nothing off yet.
4. Copy the data and try a normal day. The daily user works in the new version for a few days while the old one still runs.
5. Switch at a quiet time. Pause changes on the old system, copy the last of the data, then point everyone to the new one.
6. Leave the old system untouched for a few weeks. It is your way back if something turns up late.

Agree before step 5 what would make you switch back, such as missing records or a task that no longer works. Deciding that in advance turns a panic into a plan.

What should the review cover?

What the move taught you, because the first move exists to teach you how to do the others. Once it has settled, sit down for an hour with everyone involved. The book's advice is to keep it blame-free and look at the process, not the person. Mistakes are expected; making the same one twice is what to avoid.

Five questions cover it:

• What took longer than planned, and why?
• What broke, and who noticed first? If a customer told you, that matters.
• Is the daily user's work easier, harder or the same?
• What does it cost each month now, compared with before?
• What would we do differently next time?

Then write the plan for everything else. Group the remaining apps into small batches, easiest first, each one reusing the setup the first move built. Leave billing, payments and anything customer-facing until the team has done a few moves and trusts the process.

If the monthly cost surprised you, our post on why cloud bills keep growing covers what to check.

What should you expect from an outside partner?

That they work themselves out of a job. Most small businesses bring in outside help for a cloud move, and that is sensible. The book draws a clear line, though. A partner doing the hands-on work early is fine. A partner who stays the main pair of hands is a warning sign, because your own people never learn the system. Progress is fast while the partner is there, and confusion sets in when they leave.

Before you hire anyone, ask:

• Whose name is the cloud account in? It should be yours.
• What do we get at the end? Look for written notes on how everything is set up, and every login handed over.
• Who on our side will you teach, and how? Even in a five-person business, one person should understand the setup.
• Where can we practise safely? A separate test space lets staff try things without touching the live system.
• What happens if we stop working with you? Our post on keeping the right to leave covers what to look for.

One more lesson from the book's six-month story: give the people doing the work time to learn during working hours, not on their weekends. A cloud move that costs you your best staff has not saved anything.

Where do you go from here?

Once the first app is on AWS, check the new account before anything important lives there. Our free 30-point AWS security check takes about half an hour and gives you a fix list ordered by risk.

If the first thing you want to move is your website, there is a simpler route: a site built with Quantum Accord is hosted for you, and once you have bought it you can download its files and move it whenever you like.