How to move your on-premises server to the cloud

Moving an on-premises server to the cloud is one of the most common SMB IT projects, and one of the most commonly botched. The mechanics of the move are not hard – copy the server, point users at the new location, decommission the old one. The hard part is everything around it: figuring out what the server actually does, deciding which workloads belong in the cloud at all, picking a destination platform that fits the business, and managing the cutover without breaking what people use every day.

This guide walks through how to plan and execute a server-to-cloud migration honestly. It covers what to assess before you touch anything, which workloads are good cloud candidates and which ones should stay where they are or be replaced entirely, how Azure compares to AWS and other options for SMBs, the three main migration strategies and when each one fits, downtime planning, and what to validate after the cutover. It assumes you have already read moving your business to the cloud: where to start and have a sense of the broader picture – this article is about the specific server migration step. For the bottom-funnel view of what a managed engagement looks like across multiple workloads, see cloud migration services for small business.

Short answer: the four decisions that drive a server migration

Before picking a tool or a platform, answer these in order. They determine everything else.

1. What is on this server? File shares, line-of-business apps, databases, print services, domain controller roles, custom scripts. List every workload, not just the obvious ones. The LOB apps in particular usually need their own per-application migration plan – covered in how to move line-of-business applications to the cloud.
2. Which workloads should move to the cloud at all? Some belong in SaaS instead. Some should stay on-prem for now. Some should be retired entirely. The cloud is not the right answer for every workload.
3. For workloads that should move, what is the right migration strategy? Lift-and-shift (fastest, no optimization), re-platform (some cloud-native benefit), or replace with SaaS (highest long-term payoff for replaceable apps).
4. What is the cutover plan? When does the old server stop accepting writes, when does the new one start, and what happens if something fails?

Get those four answers right and the migration is mostly mechanical. Skip them and you will spend the next year fixing problems that would have been obvious at the planning stage.

Server migration decisions at a glance

Workload type	Recommended destination	Why
File shares	SharePoint and OneDrive (SaaS)	Better remote access, no server to maintain, native M365 integration
Email (on-prem Exchange)	Microsoft 365 (SaaS)	Mature migration tooling, managed security, zero-server email
Active Directory / domain controller	Entra ID, optionally hybrid with one cloud-hosted DC	Cloud-native identity for new apps, hybrid for legacy compatibility
Print server	Universal Print (SaaS) or local print server	Universal Print for Microsoft 365 environments; local for high-volume printing
Line-of-business app (vendor supports cloud)	Vendor-hosted SaaS or your IaaS	Vendor support is the deciding factor
Line-of-business app (vendor on-prem only)	Lift-and-shift to Azure VM or stay on-prem	Push vendor for cloud support; lift-and-shift if you must move it
Custom in-house app	Re-platform to PaaS or rebuild as SaaS	Pure lift-and-shift wastes the cloud’s advantages
Database	Managed database service (Azure SQL, RDS) or IaaS	Managed services if compatible; IaaS if version-locked
Older app on unsupported OS	Replace, retire, or isolated IaaS	Do not lift-and-shift Windows Server 2008 to the cloud

Step 1: assess what is on the server

You cannot migrate what you do not understand. Walk through the server and document every workload. This is tedious. Do it anyway.

File shares

What folders are shared, who has access, how big is each share, when was each one last accessed? File shares are usually the easiest workload to identify and the easiest to migrate – SharePoint and OneDrive are almost always the right destination. See how to migrate a file server to SharePoint and OneDrive for the tactical execution once you have decided file shares are moving.

Line-of-business applications

Practice management, ERP, accounting (QuickBooks Desktop, Sage), industry-specific software (legal, medical, manufacturing). For each one, find out:

• Does the vendor support cloud hosting? On Azure? On AWS? Or only on-prem?
• Is there a SaaS version of the same product?
• What does the application depend on? (SQL Server version, IIS version, .NET runtime, specific Windows features)
• Who actually uses it and how often?

A surprising number of on-prem apps turn out to have a SaaS version the business never adopted. Switching to the SaaS version during the migration is usually the right call – you get out of the hosting business entirely for that app.

Databases

SQL Server, MySQL, PostgreSQL, Access (yes, still). Document version, size, dependencies, who connects to it, and whether the application that uses it could connect to a cloud-hosted version with no code changes. Older SQL Server versions (2012, 2014, 2016) sometimes have to stay on-prem because the apps connecting to them require specific drivers or behaviors.

Print services

If the server hosts print queues, you need a plan for printing after migration. Microsoft Universal Print works for most M365 environments. High-volume or specialized printing (label printers, plotters, badge printers) often needs to stay on a local print server.

Domain controller and identity

If the server is a domain controller, it cannot just be “moved to the cloud.” Active Directory needs to be planned separately. Most SMBs end up with one of three patterns:

1. Cloud-only identity (Entra ID). Best for businesses with no legacy apps that require on-prem AD.
2. Hybrid identity (on-prem AD synced to Entra ID with Entra Connect). Most common SMB pattern.
3. Cloud-hosted domain controller (DC running on Azure VM). When you need traditional AD but want no physical hardware.

Identity migration deserves its own planning phase – do not lump it in with the rest of the server.

Custom scripts, scheduled tasks, batch jobs

The forgotten layer. Old PowerShell scripts that copy files between locations at 2am, scheduled tasks that nobody documented, batch files that run a backup nobody is monitoring. These break silently after a migration. List every scheduled task on the server and decide what happens to it.

Other roles

DHCP, DNS, file replication, monitoring agents, backup software, antivirus management consoles, certificate authority. Each one needs its own answer.

Step 2: decide which workloads belong in the cloud

This is the decision most businesses skip. Once they have decided “the server is moving,” they assume everything on it moves. That is rarely the right answer.

Good cloud candidates

• File shares. Almost always belong in SharePoint and OneDrive.
• Email. Almost always belongs in Microsoft 365 or Google Workspace.
• Modern web applications. If the app is web-based and the vendor supports cloud hosting, the cloud is usually a better home.
• Backup and disaster recovery infrastructure. Cloud-native backup targets are cheaper and more durable than maintaining tape libraries or USB rotation. See cloud backup vs on-premises backup for small business.
• Anything that needs to be accessible from outside the office. Cloud is built for this; on-prem is bolted-on.

Workloads that should stay on-prem (at least for now)

• High-bandwidth local workloads. CAD file collaboration, video editing, large dataset processing. Latency to the cloud kills these.
• Specialized hardware dependencies. Old industrial control systems, certain medical devices, dongle-licensed software. The cloud cannot help.
• Regulatory restrictions. Some compliance frameworks restrict where data can be stored. Verify before assuming the cloud is allowed.
• Print servers handling high-volume or specialty printing. Universal Print covers basic needs but not everything.
• Workloads with no internet redundancy. If your office has one ISP and no backup, do not put a critical workload behind it.

If even one workload here has to stay on-prem long-term, you are looking at a hybrid architecture rather than a pure-cloud destination. That is a deliberate choice with its own operational discipline – covered in hybrid cloud for small business: what it is and when it makes sense.

Workloads that should be retired entirely

Every server migration surfaces workloads that should not be migrated at all. The legacy app that one person uses occasionally and could replace with a spreadsheet. The intranet site that has not been updated in three years. The internal tool that was built by someone who left in 2019 and nobody understands. The migration is a forcing function for the audit you should have done years ago.

Workloads where SaaS is the better answer

The trap to avoid: lifting an app to a cloud VM when the vendor offers a SaaS version. You end up with the same operational burden (OS, patches, backups, security) but with a cloud bill on top. If the app has a SaaS version, evaluate that version honestly before defaulting to lift-and-shift.

Step 3: pick the right migration strategy per workload

The “5 R’s” model from cloud-vendor literature is overengineered for most SMBs. The three strategies that actually matter are:

Lift-and-shift (rehost)

Take the server image as-is and run it as a virtual machine in the cloud. Same OS, same apps, same configuration – just running on someone else’s hardware.

When it fits:

• Vendor only supports specific on-prem configurations
• You need to move fast (decommission deadline, end of lease, hardware failure imminent)
• The application cannot be re-architected or replaced
• You will revisit the architecture later but cannot do it now

The trap: if you lift-and-shift everything, you have not migrated to the cloud. You have just moved your server room to Microsoft’s data center. You still patch the OS, you still manage backups, you still secure the workload, you still pay for unused capacity. The cloud bill replaces the hardware cost but the operational cost stays the same or goes up. The “you still pay for unused capacity” part is what most lift-and-shift environments quietly waste 20 to 40% on – see cloud cost management for small business: how to stop overpaying for what to audit first when the cloud bill keeps climbing.

Lift-and-shift is a tactic, not a strategy. Use it where it fits, not as the default. For the broader strategy framework that puts lift-and-shift in context with re-platform, re-architect, repurchase, retain, and retire, see lift and shift vs re-platform vs re-architect: choosing the right cloud migration strategy.

Re-platform

Move the workload to the cloud but adopt some cloud-native features in the process. Move SQL Server to Azure SQL Database (managed service) instead of running it on a VM. Move a web app to Azure App Service instead of an IIS server. Use cloud storage for backups instead of running a backup VM.

When it fits:

• The application supports running on a managed service
• You want some operational savings (less patching, automatic backups, easier scaling)
• You are willing to do moderate work to refactor the deployment

Re-platforming is the sweet spot for many SMB workloads. You get most of the operational benefits of cloud-native architecture without rewriting the application.

Replace with SaaS

Drop the on-prem app, adopt a SaaS equivalent, migrate the data. QuickBooks Desktop becomes QuickBooks Online. On-prem CRM becomes HubSpot or Salesforce. Self-hosted helpdesk becomes Freshdesk or Zendesk. On-prem file server becomes SharePoint and OneDrive.

When it fits:

• A mature SaaS replacement exists
• The data migration path is reasonable
• The workflow can adapt to the SaaS product’s conventions
• The long-term operational savings justify the switching cost

This is usually the highest-leverage path. You are not just moving the workload, you are getting out of operating it entirely.

How most SMBs end up

A typical 40-person SMB server migration ends up something like:

• File shares: Replace with SaaS (SharePoint and OneDrive)
• Email: Replace with SaaS (Microsoft 365)
• Active Directory: Re-platform (hybrid identity with Entra Connect)
• Practice management app: Lift-and-shift to Azure VM (vendor only supports on-prem)
• Custom intranet site: Replace with SharePoint pages
• Print server: Stay on-prem or move to Universal Print
• Backup server: Replace with cloud backup service

Mixed strategies are normal. The wrong answer is forcing one strategy on every workload.

Step 4: pick a destination platform

For most SMBs, the realistic options are Microsoft Azure, Amazon Web Services, or a smaller managed cloud provider. The full breakdown lives in Azure vs AWS for small business; this section covers the decision drivers as they apply to a server migration specifically.

Azure usually wins for Microsoft-shop SMBs

If your business is on Microsoft 365, your domain is Active Directory, your apps run on Windows Server, and your team uses Outlook and Teams – Azure is the path of least friction. The integration with Entra ID, the licensing crossover with Microsoft 365, and the familiar admin experience all matter. A 25-person SMB doing a server migration will almost always have a smoother experience on Azure than on AWS. If you are not yet sure what Azure even is or how it relates to the M365 you already pay for, see what is Microsoft Azure and what can it do for a small business for the awareness primer.

AWS makes sense for specific workloads

Broader service catalog, more compute options, often cheaper at scale. AWS is genuinely the better choice when you have specific requirements (a particular database service, a niche compute type, geographic regions where Azure is weaker). For pure server lift-and-shift on a Microsoft stack, AWS does not bring enough advantage to justify the integration cost.

Smaller managed providers

Companies like DigitalOcean, Linode, Vultr, Rackspace, and others run smaller cloud platforms. They can be cheaper and simpler for basic workloads, but they lack the depth of services and the SMB-aware tooling that Azure and AWS provide. For a single VM running a single app, they can be fine. For a full server migration with identity, file storage, and multiple workloads, they are usually a step backward.

Avoid the trap of “we will run it ourselves at a colo”

Some SMBs decide the cloud is too expensive and put their server in a colocation facility instead. This is rarely the right answer. You still have hardware to refresh, you still have OS to patch, you still have to drive to the colo when something physical breaks, and you do not get any of the cloud’s elastic capabilities. Colo can be the right answer for very specific workloads (compliance, latency, hardware-locked apps), but not as a general response to cloud cost concerns. The honest cost picture – including the three-year TCO comparison vs staying on-prem – is in how much does cloud migration cost for a small business.

Step 5: plan the cutover

The actual migration day is where most projects fail in execution. Plan it like an outage, because it is. The cloud migration checklist for small business covers the cutover-day runbook items in detail – what to back up immediately before, when to put the old server in read-only, what smoke tests to run before declaring cutover complete, and how to define your rollback decision point.

Establish a cutover window

Pick a low-traffic window (overnight, weekend, holiday). Communicate it to users at least two weeks in advance. Tell them what will be unavailable, when, and what to do if something does not work after the cutover.

Run in parallel before cutting over

For most workloads, you can copy data to the cloud destination while the on-prem server stays live. Then on cutover day, you do a final sync of changes and switch DNS or pointers. The shorter the time between final sync and cutover, the less data drift you have to reconcile.

Have a rollback plan

If something fundamental breaks, can you go back to the on-prem server? For how long? Document the rollback steps before you start, not at 3am when the migration is failing.

Test the destination before cutting over

Spin up the new environment, restore the data, and have a few users verify the workload works. This catches missing dependencies, broken integrations, and configuration drift before the production cutover.

DNS and connection cutover

Most workloads are accessed by hostname. Update DNS to point at the cloud destination, or update the application to point at the new server. Plan for DNS TTL – if your TTL is 24 hours, the cutover is not “done” for 24 hours after the change.

Step 6: validate after the migration

The migration is not done when the data is copied. It is done when the workload is verified to work as well or better in the new location.

Functional validation

• Users can log in
• Files open from the new location
• Applications run with no errors
• Print jobs reach the right printer
• Scheduled tasks run on schedule
• Email sends and receives
• Backups run and complete

Performance validation

Cloud is sometimes faster than on-prem (especially for remote users) and sometimes slower (especially for users on slow internet). Measure actual performance after the migration and compare to expectations.

Security validation

The cloud-hosted version of the workload needs the same security posture as the on-prem version, plus the cloud-specific controls. Re-validate access, MFA, encryption, backup integrity, and audit logging in the new environment. See Microsoft 365 security hardening for small business if the migration includes M365. The migration window itself also has a separate security profile that deserves its own plan – leftover service accounts, replicated permission sprawl, and parallel-environment exposure all happen during the cutover, not after – covered in how to keep your data safe during a cloud migration.

Cost validation

Look at the actual cloud bill after 30 days of running the workload. If it is materially higher than your estimate, find out why – usually it is unused or oversized resources, forgotten dev environments, or storage you forgot to clean up after the migration.

Step 7: decommission the old server

This step gets skipped more than any other. The old server keeps running “just in case” for two years, accruing electric bills, support contracts, and security debt.

Before decommission

• Confirm every workload is verified working in the cloud
• Confirm at least one full backup cycle of the new environment has succeeded
• Notify users the old environment is being shut down
• Wait the agreed retention period (usually 30 to 90 days)

During decommission

• Power off the server
• Remove from monitoring
• Cancel support contracts and warranties
• Cancel any software licenses tied to the server
• Update documentation to reflect the new architecture

Hardware disposal

• Secure data wipe (DOD 5220.22-M or NIST 800-88 standards) before disposal
• Document the wipe with a certificate
• Resell, recycle, or repurpose – in that order

For regulated industries (HIPAA, financial services, defense contractors), the data destruction step has specific requirements. Verify the standards your compliance framework requires. For the full decommission sequence – validation, standby window, data destruction by regulatory framework, hardware disposal options, and the documentation that closes the loop – see how to decommission old servers after a cloud migration.

How long does a server migration take?

Server complexity	Typical timeline	What drives the variance
Single-purpose server (file shares only, or email only)	4 to 8 weeks	Data volume, cleanup needed before migration
Multi-purpose server (files + apps + identity)	8 to 16 weeks	Workload count, application complexity, identity strategy
Server with custom or legacy applications	12 to 24 weeks	Vendor cooperation, code refactoring, testing scope
Multi-server environment (full data center migration)	6 to 18 months	Number of servers, dependencies between them, change tolerance

These timelines include planning, testing, and validation – not just the data copy. A vendor quoting “we can move your server in two weeks” is usually skipping the steps that prevent failure.

Common server migration mistakes

1. Lift-and-shift everything by default. If you do not evaluate SaaS and re-platform options for each workload, you are paying cloud prices for on-prem operations.
2. Migrating identity last. Active Directory needs to move first or in parallel – not after the apps that depend on it.
3. Copying without cleanup. The old server has files nobody has touched in a decade, accounts for people who left in 2018, and configurations from migrations past. Clean up before you copy, not after.
4. Skipping the bandwidth check. Cloud-hosted servers are accessed over the internet. If your office bandwidth was sized for local traffic, it will struggle when half the workload moves outside the building.
5. No backup verification before migration. The migration is the worst time to discover the backup has been failing silently. See how to test your business backup and why most companies never do.
6. Forgetting the integrations. The CRM that pulls from the file server, the reporting tool that queries the database, the legacy printer that needs an old driver – integrations break first and most often.
7. Underestimating user training. The application looks the same on the cloud VM, but the file paths changed, the print queues changed, the Wi-Fi network changed. Users need to know what is different.
8. Not planning the decommission. Two years later, the old server is still racked, still drawing power, still under support contract. Plan the decommission as part of the migration plan, not as a future task.

How Sequentur approaches server migrations

Sequentur is a security-first MSP / MSSP for small and mid-sized businesses across the 15-to-250-employee range, including both general SMBs and regulated industries like healthcare, legal, financial services, and defense contractors. Server migrations are one of the most common project engagements we run, especially for businesses approaching a hardware refresh cliff or coming out of a remote-work expansion that exposed how much their on-prem infrastructure was holding them back.

Our migration engagements start with the assessment – what is on the server, what should move, what should stay, what should be replaced – before any platform decision is made. We are honest about which workloads do not belong in the cloud, and we will tell you when a SaaS replacement is a better answer than a lift-and-shift to Azure even when that means less project revenue for us. The migration itself is scoped as a project (discovery, planning, phased execution, validation), and once the new environment is stable it transitions into managed IT through our managed Microsoft 365 services or full managed IT support engagements for ongoing operation.

If you are facing a hardware refresh decision, an end-of-life server, or a cloud migration that has been on the roadmap for two years, schedule a call and we can walk through what your specific server runs and what a phased migration would actually involve.