Moving your business to the cloud goes well when it is done in stages: review what you have, choose a platform, migrate one workload at a time, test, switch over with a way back, then tune cost and security. It goes badly when it is treated as a single weekend job. This guide sets out a plan a small or medium business can follow, and answers the two questions owners ask most: who is responsible for security once you are in the cloud, and where your data is actually stored.
What moving to the cloud means for a small business
The cloud is a provider's data centre that you rent by usage instead of buying hardware. The server in the back room that runs your file shares, your job database or your line-of-business application is replaced by services run by a provider such as Amazon Web Services (AWS), Microsoft Azure or Google Cloud. Most businesses already use some cloud software, such as email or accounting. A migration project deals with whatever is still on your own equipment.
It helps to know the three service models, because they decide how much work stays with you. Microsoft describes them in its shared responsibility guidance:
- Infrastructure as a service (IaaS): you rent virtual machines and manage the operating systems and applications on them.
- Platform as a service (PaaS): you deploy your application or database without managing the virtual machines or operating systems underneath.
- Software as a service (SaaS): you use a ready-made application, such as a hosted email or accounting product.
The six stages of a cloud migration
| Stage | What happens | What you should have at the end |
|---|---|---|
| 1. Review | List every server, application, database, file share and integration, and who relies on each | An inventory with a decision for each item: move, replace, rebuild, retire or keep |
| 2. Choose a platform | Compare providers and service models against what your systems need | A chosen platform and region, and a written cost estimate |
| 3. Migrate in stages | Move one workload at a time, starting with a low-risk one | Each workload running in the cloud while the old copy still exists |
| 4. Test | Staff run their real daily tasks against the new environment | A signed-off test list, including backups and restores |
| 5. Switch over | Final data copy, change of addresses, old system set to read-only | A working system and a rollback plan you did not need |
| 6. Optimise | Review spending, access and security settings once real usage is known | Right-sized resources, cost alerts and a security baseline |
Stage 1: Review what you have
Start with an inventory, not a provider's brochure. For each system, write down what it does, who uses it, what data it holds, what it connects to, how it is backed up and when its licence or hardware support ends. Then decide what to do with it. An ageing file server might simply become cloud file storage. A custom job-tracking database might be moved as it is now and rebuilt later. Some things can be switched off altogether, and finding those is the cheapest win in the project.
Stage 2: Choose a platform
The right platform depends on your systems, not on which provider is biggest. Compare the options on a few practical points:
- the software you already run and the licences and skills you already have
- whether the services you need are offered in an Australian region
- how staff will sign in, including multi-factor authentication (a second proof of identity at sign-in)
- backup, restore and disaster recovery options
- how billing works and who will watch it
Ask for a written cost estimate before committing. Cloud bills are driven by the size and running hours of virtual machines, the amount and type of storage, data transferred out, backup retention, software licences and support plans.
Stage 3: Migrate in stages
Move one workload at a time and begin with something that would not stop the business if it misbehaved briefly, such as an archive file share. The first move teaches you how long data copies take over your internet connection and what staff find confusing. Keep the old system intact until the new one has been accepted. Data moves need particular care: agree on a cut-off time, copy, compare record counts and totals, then spot-check real records with the people who know them.
Stage 4: Test
Testing means staff doing their real work in the new environment: raising an invoice, opening last year's drawings, running the month-end report. Write the list of tasks before you start and tick them off. Test the unglamorous parts too: restore a file from backup, sign in from a phone, and check that printers and integrations still work.
Stage 5: Switch over with a rollback plan
Pick a quiet time for the business, tell staff what will change, and write down the steps in order. The rollback plan is the part people skip. It answers one question: if the new system is not usable by an agreed time, how do we go back? That means keeping the old system switched on but read-only, knowing how to point addresses back to it, and deciding in advance who makes the call.
Stage 6: Optimise cost and security
After a period of real use, review what you are paying for and adjust resources that were sized on a guess. Set budget alerts so that an unexpected bill is noticed early. Then tighten security: remove accounts that were only needed for the migration, check who has administrator rights, and confirm backups are running and restorable.
Shared responsibility: what the provider secures and what stays with you
Moving to the cloud does not hand all security to the provider. Microsoft's shared responsibility model states the split plainly: the provider looks after the physical data centre, the physical network and the physical hosts, and for every type of cloud deployment the customer owns its data and identities.
According to Microsoft, whatever service model you choose, you always keep responsibility for four things: your data, the devices that connect to it, your user accounts, and access management such as multi-factor authentication. With IaaS you also manage the operating systems and applications on your virtual machines, which means patching them is still your job. With SaaS the provider takes on far more, but deciding who can sign in and what they can see remains yours.
For a small business this translates into a short list: turn on multi-factor authentication for everyone, remove access on the day a person leaves, keep your own backups of important data, and patch anything you manage yourself. These are the basics of cyber security anywhere.
Where your data is stored: Australian regions
Cloud providers group their data centres into regions, and you choose the region when you create a resource. All three large providers list regions in Australia:
- AWS: the AWS Regions list shows Asia Pacific (Sydney) and Asia Pacific (Melbourne). Sydney is enabled by default; Melbourne has to be enabled in your account before you can use it.
- Microsoft Azure: the Azure regions list shows Australia East (New South Wales), Australia Southeast (Victoria) and Australia Central (Canberra), plus Australia Central 2, to which access is restricted.
- Google Cloud: the Google Cloud regions and zones list shows Sydney and Melbourne.
These lists change, so check them when you plan. Choosing an Australian region for your main resources is only part of the answer. Ask where backups, logs and any disaster recovery copies are kept, whether every service you plan to use is available in that region, and where each SaaS product you rely on stores its data, because that is decided by the software vendor rather than by you.
Who does the work
Anything involving servers, databases or custom software is usually better handled by people who do it regularly. Comingwave is an Australian technology company that provides cloud migration and hosting for small and medium businesses, along with managed IT support once systems are running. If you would like a written plan and quote for your own move, send us an enquiry.
Key takeaways
- Start with an inventory and a decision for each system; some will be retired or replaced, not moved.
- Migrate one workload at a time and keep the old system until the new one is accepted.
- Write the rollback plan before switch-over day, including who decides to use it.
- The provider secures the data centre; your data, accounts, devices and access settings remain your responsibility.
- Choose an Australian region deliberately and ask where backups, logs and SaaS data are held.
Frequently asked questions
How long does it take to move a small business to the cloud?
It depends on how many systems you have, how much data must be copied, and whether applications are moved as they are or replaced. Once the review stage has put a decision against every system, a realistic schedule can be written. You do not have to move everything at once.
Is the cloud more secure than a server in our office?
It can be, because the provider takes over physical security and the upkeep of the underlying hardware. It is not automatic: under the shared responsibility model you still control accounts, access, devices and your data.
Will our data stay in Australia?
It will if you choose Australian regions for your resources and confirm the same for backups, logs and recovery copies. Check separately for each SaaS product you use, since its vendor decides where that data is held.
What does moving to the cloud cost?
There are two parts: the one-off migration work and the ongoing usage. Usage is driven by virtual machine size and running hours, storage, data transferred out, backups, licences and support. Ask for a written estimate that lists each driver.