Moving servers and business applications to the cloud: a migration plan for SA small businesses and councils

Many South Australian small businesses, not-for-profits and councils still run a server in a cupboard or a rented rack: a line-of-business application, an accounting or rates database, a print server, a domain controller and a few shared folders. Sooner or later something forces a decision. The hardware warranty ends, the operating system reaches end of support, the person who set it up leaves, or an insurer starts asking about backups. Moving to the cloud is often the right answer, but a migration done in a rush can cost more, break things staff depend on and leave security gaps. This guide explains, in plain words, how to plan a move of servers and business applications to AWS or Microsoft Azure: what to inventory, how to decide what happens to each system, how to keep data in Australia, how to cut over safely and what to tidy up afterwards. It is practical guidance, not a quote, and every environment is different.

Why now: end-of-support dates are close

Microsoft’s extended support for Windows Server 2016 ends on 12 January 2027, and extended support for SQL Server 2016 ended in July 2026. After end of support there are no more security updates unless you pay for Extended Security Updates, and patching operating systems and applications is part of the ACSC Essential Eight. If a server runs either product, you need a plan this financial year whether or not you move to the cloud. Check your own products’ dates in Microsoft’s lifecycle pages rather than relying on a list.

Step 1: know what you are moving

Most migration problems come from something nobody knew was there. Before choosing any tool, build a simple inventory, one row per server or application:

• What it does and who relies on it, including the business owner, not only the IT contact.
• What it talks to: other servers, printers, scanners, door controllers, payment terminals, bank file exports, scheduled tasks and the email relay that sends invoices.
• Versions and licences for the operating system, database and application, and whether the vendor supports the application in the cloud.
• Size and growth of data, and how busy the server really is over a normal month.
• How long it can be down and how much recent data you could afford to lose. These become the recovery time and recovery point targets.
• Information it holds: personal information, council records, health or financial data, and any residency or retention rules that apply.

Tools such as Azure Migrate and AWS Application Discovery Service can collect server and dependency data automatically, but a 30-minute conversation with each system owner usually finds the parts a tool misses.

Step 2: decide what happens to each system

Not everything should be lifted into a cloud server. AWS describes the options as the “7 Rs”, and the same choices apply on Azure:

Option	What it means	Often suits
Retire	Switch it off.	Old applications nobody uses, kept “just in case”. Archive the data properly first.
Retain	Leave it where it is for now.	Systems tied to on-site equipment, or due for replacement within a year.
Repurchase	Replace with a software-as-a-service product.	File shares (to SharePoint and OneDrive), email, accounting, CRM and HR systems.
Rehost	Move the server as it is to a cloud virtual machine.	Line-of-business applications the vendor supports on a virtual machine, when time is short.
Relocate	Move a whole virtualisation platform without changing the servers.	Larger VMware estates; rarely the right fit for a small organisation.
Replatform	Make small changes to use managed services.	Moving a SQL Server database to a managed database service, or a website to static hosting.
Refactor	Rebuild the application for the cloud.	Custom software you own and plan to keep for years. See our guide to legacy application modernisation.

For a typical small organisation, the result is a mix: shared folders go to Microsoft 365 (our file server to SharePoint checklist covers that), one or two applications are rehosted or replatformed, and a few old systems are retired. Sign-in often moves from an on-site domain controller to Microsoft Entra ID with devices managed in Intune.

Step 3: keep data in Australia and set up the foundations

Both major clouds have Australian regions: AWS has Asia Pacific (Sydney) and Asia Pacific (Melbourne), and Azure has Australia East and Australia Southeast, with Australia Central regions in Canberra aimed at government. Choose your regions deliberately, and use policy to stop resources being created elsewhere. Remember that backups, logs, monitoring tools and AI services can store data too, so check where each one keeps it. Our guide to Australian data residency explains the questions to ask.

Before the first server moves, put the foundations in place:

1. Accounts or subscriptions in your organisation’s name, with separate production and non-production environments. A multi-account landing zone shows the pattern.
2. Strong administrator access: multi-factor authentication, named accounts, no shared root or global admin logins in daily use, and break-glass accounts stored safely.
3. Network design: how staff and sites will reach the applications (VPN, private connections or published applications), with nothing exposed to the internet that does not need to be.
4. Logging and monitoring switched on from day one and kept long enough to investigate an incident.
5. Backups that are separate from the servers they protect, cannot be deleted by a single compromised account, and match your recovery targets. See backup and disaster recovery.
6. Budgets and cost alerts, so the first bill is not a surprise. Our cloud cost control guide covers tagging, alerts and safe savings.

Step 4: estimate running costs honestly

A cloud server is not automatically cheaper than the one in the cupboard. The comparison should include what you pay now for hardware replacement, warranties, power, backup software, after-hours support and the risk of a failed disk, against the monthly cloud cost of compute, storage, backups, data transfer and licences. A few things change the numbers a lot:

• Size from real usage, not the original server specification. Most small servers are idle most of the day.
• Check licensing for Windows Server, SQL Server and the application itself. Some licences can be brought to the cloud, others cannot, and some vendors charge differently for cloud hosting.
• Turn off what does not need to run overnight, such as test environments.
• Ask for the running-cost estimate in writing, with its assumptions, as well as the migration price.

Step 5: test, cut over and keep a way back

Migration tools such as AWS Application Migration Service and Azure Migrate replicate servers continuously, so the final switch can be short. The tool is the easy part; the plan around it matters more:

1. Do a test migration first and have the business owner check the application with real tasks: run a report, print an invoice, export a bank file, scan a document.
2. Agree a cut-over window outside busy periods, such as end of month, rates notices or payroll, and tell staff what will change and when.
3. Freeze changes on the old server during the final sync, then update DNS names, shortcuts, printers and integrations.
4. Write down the rollback point: what would make you go back, who decides, and how long the old server stays available (often two to four weeks, switched off but intact).
5. Check the essentials the day after: backups ran, monitoring alerts work, scheduled tasks ran and emails from the application arrived.

Our guide to software testing and user acceptance testing has a simple test plan you can adapt.

Step 6: tidy up after the move

• Decommission the old hardware properly: wipe or destroy disks with a record of it, and cancel support contracts you no longer need.
• Update documentation: the inventory, the network diagram, who to call, and your incident response plan.
• Run a restore test within the first month, and put one on the calendar every quarter or half year.
• Review size and cost after 30 and 90 days, once you have real usage data.
• Update your cyber insurance and procurement answers, since hosting, backups and admin access have all changed. See cyber insurance questionnaires.

Councils and government work

Councils and agencies have a few extra checks. Records held in a migrated system still fall under the State Records Act 1997 and the relevant disposal schedules, so plan how records are kept, retained and disposed of in the new environment (our council records and FOI guide has more). Agencies should check their obligations under the SA Information Security Management Framework, and anyone supplying an APRA-regulated entity should read our CPS 230 guide. Write ownership of the cloud accounts, data return and exit help into the contract; our guide to provider due diligence and exit planning explains what to ask for.

A 90-day plan

1. Weeks 1 to 3: inventory and decide. List every server and application, talk to each owner, record recovery targets and end-of-support dates, and choose retire, retain, repurchase, rehost, replatform or refactor for each.
2. Weeks 4 to 6: foundations. Set up accounts in your name, Australian regions, MFA for administrators, networking, logging, backups and budgets.
3. Weeks 7 to 10: test migrations. Replicate the first systems, test them with the business owners and fix what breaks.
4. Weeks 11 to 13: cut over and tidy up. Move production in agreed windows, keep the rollback option for a few weeks, run a restore test, then decommission the old hardware.

Questions to ask your supplier or IT team

1. Which of our servers or databases reach end of support in the next 18 months?
2. For each system, are we retiring, replacing, moving or rebuilding it, and why?
3. Will every copy of our data, including backups and logs, stay in Australia?
4. Whose name are the cloud accounts in, and who holds the administrator logins?
5. What will this cost to run each month, and what assumptions is that based on?
6. How will we test before cut-over, and what is the rollback plan?
7. When will we do the first restore test?

Talk to an Adelaide team

If you have a server approaching end of support or an application you want off ageing hardware, talk to us about a cloud migration plan or call 0402 401 584. We can quote a migration assessment that produces an inventory, a decision for each system, a running-cost estimate and a staged migration plan your team can review before anything moves. Learn more about our DevOps and cloud engineering and managed IT and cyber security services.