For most small and mid-sized businesses in Chicago and the northwest suburbs, a cloud migration means four specific things: email and identity move to Microsoft 365, file shares move off a Windows file server into SharePoint and OneDrive, line-of-business applications either move to a vendor-hosted version or get rehosted, and whatever is left in the server room gets decommissioned or reduced to one box that stays for a reason. The work that decides whether it goes well is not the copying. It is the discovery done before anyone commits, the permissions rebuild, and the applications nobody wants to talk about.
What does “moving to the cloud” actually mean for a small business?
It means moving four things, in this order of difficulty: email, files, applications, servers. Very few companies move all four, and fewer should.
Email and identity. If you are running on-premises Exchange or a hosted POP account, this moves first and pays off fastest. It brings Microsoft Entra ID with it, which becomes the account system everything else authenticates against. Once identity is in the cloud, multi-factor authentication and conditional access are available, and the security baseline improves more than the file move ever will.
Files. The shared drive everyone calls the S: drive becomes SharePoint document libraries and OneDrive. This is the step that looks simple and is not.
Line-of-business applications. The ERP, the practice management system, the estimating package, whatever the business actually runs on. Three outcomes: the vendor has a hosted version and you switch, the vendor supports the application on a cloud server and you rehost it, or the vendor does neither and it stays where it is. That third case is more common in manufacturing and distribution than most people expect.
Servers. What is left is often a domain controller, a print server and a backup appliance. Sometimes that collapses to nothing. Sometimes it collapses to one small server that stays on site for a specific reason, which is a fine outcome, not a failure.
What should discovery surface before anyone commits?
Discovery exists to find the things that will stop the project, and it happens before a scope or a date is agreed to. A migration quoted without it is a guess, and the schedule will move.
A discovery pass should produce, in writing:
- A full application inventory. Version, vendor, who uses it, and whether that vendor supports it in a cloud configuration. Not “we think it works.” A statement from the vendor.
- Data volume and file count, separately. Two terabytes in 30,000 large files is a different migration from 600 GB in 4 million small ones. File count drives migration time more than size does.
- The actual upload speed at the office, not the number on the invoice. Business cable and DSL are asymmetric and the upload side is what matters. A 40 Mbps upload link fully saturated moves roughly 400 GB in a day on paper, and no real link runs saturated during business hours. Two terabytes over that circuit is a week of background copying at best, and that belongs in the plan rather than in a discovery on Friday night.
- A permissions map of the file server, expressed as groups rather than individual names.
- Mailbox inventory. Shared mailboxes, room and resource mailboxes, distribution groups, public folders, anything over 50 GB.
- Where the PST files are. They are on desktops and they are not in the backup.
- Anything physically attached to a server. A license dongle, a serial connection to a machine on the floor, a fax board, a time clock. These are what keep a server on site.
- What happens if the internet is down for four hours. Before the move, some things still work. After it, usually nothing does. That changes what the network has to look like, which is covered on the managed network infrastructure page.
What is the realistic sequence of a cloud migration?
Email first, files second, applications third, servers last. Each step depends on the one before it. RJ2 is a Microsoft CSP reseller and scopes each Microsoft 365 migration as a per-user setup and a migration project with a statement of work.
- Tenant and identity. Build the Microsoft 365 tenant, sync or create accounts, decide whether the on-premises directory stays authoritative during the transition. Turn on the security baseline now, not later.
- Mail pre-stage. Copy the bulk of the mail before anyone changes anything. The final pass is a delta.
- DNS cutover for mail. Lower the MX record TTL several days ahead so the change lands in minutes instead of hours. Autodiscover, SPF, DKIM and DMARC all get set in the same sitting, because mail authentication that is half configured is worse than none.
- File pre-seed. Copy the file server up over nights and weekends while people keep working normally. This takes calendar time and almost no attention.
- Permissions build. Structure the sites and libraries and grant access by group. Not a photocopy of the old folder tree.
- Cutover weekend. Final delta, old share goes read-only, everyone gets repointed.
- Applications. One at a time, each with its own back-out plan.
- Decommission. Only after a full monthly cycle has run clean, month-end close included.
What actually goes wrong during a cloud migration?
Six things, and five of them are predictable.
Permissions that do not map. File server permissions are set folder by folder, nested several layers deep, often on individual users rather than groups, with exceptions added over fifteen years by people who no longer work there. SharePoint does not work that way. It inherits down from a site, and deep per-folder exceptions are how a SharePoint site becomes unmanageable inside a year. The right move is to rebuild access by group at the library level, which requires someone to decide who should have access, which is a business decision and not an IT one. That decision is the most common reason a file migration slips.
Shared mailboxes. They migrate as shared mailboxes and need no license until they pass 50 GB or need an archive or a legal hold. Finding that out afterward means either a surprise on the bill or a mailbox that quietly stops receiving.
PST files. Years of archived mail on individual desktops, outside every backup you have, frequently corrupted, occasionally the only copy of something a lawyer will ask for. They have to be found, ingested, then deliberately retired, or they come back as a ticket in eight months when a laptop dies.
The application the vendor never certified for cloud. The vendor will say it is supported and then not support it. Get the position in writing. The genuinely hard cases are applications that need a mapped drive and low latency to a database on the same LAN, applications tied to a physical dongle, and anything that talks to equipment on the floor. The application side gets scoped on the enterprise applications page.
Bandwidth at the office. The pattern that fails is assuming the circuit is fine because email and browsing feel fine today, then asking it to carry the migration and the new daily workload at once.
The users who keep working out of the old location. Nobody plans for this and it does the most quiet damage. For a month after cutover some share of your staff still has a mapped drive letter, a desktop shortcut or a saved path aimed at the old server, and they keep saving there. Then someone finds a month of work that never went up. The fix is mechanical, not motivational: make the old share read-only at cutover rather than leaving it writable just in case, pull the drive mappings out of the login script that same weekend, and check the old volume for new writes on days three, ten and thirty.
What does a cutover weekend look like?
A well-run cutover weekend is boring, because the work happened in the two weeks before it. Friday evening the old share goes read-only and the final delta starts. Saturday is the delta finishing, the DNS change if mail moves in the same window, permissions verified against the map, and a short list of people testing from the office and from home. Sunday is for what only shows up under real use, which is almost always printing, scan to folder from the copier, and one application with a server name hardcoded in a config file.
Two things belong in the plan and usually are not. First, a back-out point, a specific hour on Saturday at which, if the delta has not finished or permissions are wrong, everyone goes back to the old share Monday morning. Nobody wants to use it. Every cutover should have one. Second, someone in the building Monday morning. The first two hours generate more tickets than the rest of the month, and most are 90 second fixes that become 20 minute fixes over the phone.
The disruption people actually feel is not the copying, which is invisible. It is the new sign-in prompt, the second factor, and a week of not finding something they have found the same way for a decade. That is a training problem more than a technical one, and a short session before cutover removes most of it.
How do you decide what should stay on premise?
Something stays on premise when moving it makes the business slower, less reliable, or dependent on a circuit it does not control. That is the test.
Reasons that hold up: latency-sensitive work like CAD, large video, or a database a dozen people hit constantly, where a WAN link that adds tens of milliseconds to every operation gets reported as “everything is slow” and never stops being reported. Anything wired to physical equipment, which a distribution or manufacturing operation in Elk Grove Village or Wood Dale almost always has. Work that has to continue through an internet outage, where the answer is either a local server or a second circuit with automatic failover. Both are legitimate. Doing neither is not. And a vendor who will not support the application any other way.
Reasons that do not hold up: the server is only three years old, which is a depreciation question and not an architecture one, and the data feels safer in the building, which it is not unless the backup is tested.
A common landing spot for a small office is not all in or all out. It is Microsoft 365 for mail and files, one application still running locally because the vendor requires it, one small box keeping it company, and a network built so a dead circuit is an inconvenience rather than a stoppage.
Frequently asked questions
What is included in a cloud migration for a small business?
Usually four workstreams: Microsoft 365 tenant and identity setup, mailbox migration, file shares moved to SharePoint and OneDrive, and a decision on each line-of-business application about whether it moves, gets rehosted, or stays. Server decommissioning comes last, after a full month of clean operation.
How long does a cloud migration take?
Calendar time is driven by data volume, file count and the upload speed at your office, not by headcount. The pre-seed copy of a file server runs for days or weeks in the background before anyone notices, and the cutover itself is usually a single weekend.
Will our business have downtime during a cloud migration?
A planned migration puts the disruptive steps on a weekend and keeps people working normally during the background copying. The most common Monday issues are printing, scan to folder from the copier, and shortcuts still pointing at the old location.
What usually goes wrong in a cloud migration?
Permissions that do not translate from the old file server, PST archives nobody knew about, shared mailboxes handled incorrectly, an application the vendor will not support in the cloud, not enough upload bandwidth at the office, and users who keep saving to the old share for weeks after cutover.
Should everything move to the cloud?
No. Latency-sensitive work, anything physically connected to equipment, and any process that has to keep running during an internet outage are real reasons to keep a server on site. Most small and mid-market businesses end up with a mix.
Do we need to upgrade our internet before moving to the cloud?
Often yes, and it should be answered during discovery rather than during cutover. Once mail, files and applications are all off site, the internet circuit becomes the single point of failure for the whole business, which usually justifies a second circuit or automatic failover.