When most people picture a Microsoft 365 migration, they picture a fairly standard office. Desks, laptops, Outlook, a shared drive with Word documents and spreadsheets. The kind of environment where moving to Exchange Online and SharePoint is mostly a paperwork exercise.
Design studios are not that.
This case study walks through a migration we recently completed for a sign-making business — a small team, but one running a genuinely demanding setup: Adobe Illustrator, RIP software driving large-format printers, and over a decade of design files sitting on an ageing Windows Server 2016 file share. Just over 4TB of it.
If you run an SMB and you’ve been wondering whether modernising your IT is realistic for a business like yours — especially one that relies on specialist software and big files — this is exactly the kind of project that proves it is.
The Starting Point
The client had two things holding them back, and one quiet ambition driving them forward.
Holding them back: hosted Exchange for email, and an on-premise Windows Server 2016 file share for everything else. The file share contained over 4TB of design work — years of vector files, raster artwork, RIP-ready output, and archived projects. Some of those archives were single ZIP files weighing in at 250GB or more.
Driving them forward: they wanted to work from anywhere. Home, client sites, a coffee shop before a meeting. The on-prem file server made that effectively impossible without clunky VPN workarounds, and even then, the performance over a remote connection wasn’t realistic for the file sizes involved.
There was no crisis pushing the migration. No failing hardware, no security incident, no licensing cliff edge. Just a clear-headed decision to modernise properly — and the patience to plan it rather than rush it.
That patience mattered, because design studios add complications that a typical SMB migration doesn’t have to think about.
Why This Migration Wasn’t a Standard One
A few things make a design-heavy environment genuinely different:
- RIP software. The Raster Image Processor software that drives large-format printers expects files to behave like local files. SharePoint and OneDrive are not local files in the traditional sense — they’re synced, cached, or streamed.
- File sizes. Working files in Illustrator with embedded raster content can easily run to hundreds of megabytes. Archived project folders run to tens or hundreds of gigabytes.
- Linked files. Illustrator and similar tools frequently rely on linked assets — if those paths break during a migration, files open with missing artwork and a lot of red question marks.
- Mapped drive habits. Designers tend to have years of muscle memory tied to drive letters and specific folder paths. Change those and workflows break overnight.
None of this is insurmountable. But it does mean you cannot treat the migration as a tick-box exercise. We had been planning the move for a long time specifically to validate that SharePoint, OneDrive and the client’s design tools could coexist properly.
The Testing Phase: Where the Real Work Happened
Before committing to anything, we spun up a fresh Microsoft 365 tenant with no domain attached and ran a dry run with a handful of representative working directories.
We tested two configurations:
Full sync — files mirrored locally on each client device. Familiar to designers used to working off a local drive, but problematic when you’re talking about 4TB of data on machines with smaller SSDs.
Files On-Demand (online-only mode) — files appear in Explorer but only download when opened. Practical for storage, but the open question was always going to be performance.
We expected Files On-Demand to feel slower than the existing LAN-based file server. After all, the original setup had everything sitting on the same local network as the workstations, while OneDrive and SharePoint are reaching out over the internet.
What we actually found surprised us: performance over the WAN was quicker than the original LAN file server.
That’s worth sitting with for a moment, because it goes against most people’s instincts. Modern Microsoft 365 infrastructure, combined with a decent business internet connection and the way OneDrive handles file streaming, simply outpaced an older on-prem server that had been chugging along for years. The client’s hardware was capable, but Microsoft’s data centres and global content delivery are in a different league.
The other early gotcha was file path length — Windows has a 260-character path limit by default, and decades of deeply nested folders meant we hit it repeatedly. We resolved this through a few rounds of renaming with the client’s input, since they were the only ones who could sensibly decide which folder names could be shortened without losing meaning.
The folder structure itself was straightforward — heavily nested but with very simple permissions, since only two users needed access. That made one part of the project mercifully simple.
The Cutover: Email First, Then 34 Hours of Files
With testing done and confidence built, we moved to the actual migration.
Email: A Minute From Old to New
For email, we used Exchange Online’s built-in IMAP Migration tool to pull mail across from the hosted Exchange platform. With the migration batches complete and inboxes mirrored, we cut the DNS records over via Cloudflare.
We had prepared the DNS TTL well in advance so propagation would be fast, and we monitored global DNS propagation in real time during the switch. The cutover was complete within a minute. Not a single email was lost.
There’s a temptation in migrations like this to over-engineer the email side — third-party tools, lengthy coexistence periods, hybrid setups. For a two-user business on hosted Exchange, none of that was necessary. IMAP migration is sometimes dismissed as the “basic” option, but for the right scenario it’s clean, free, and reliable.
Files: A Weekend Marathon With SPMT
The 4TB file migration was where the real time investment lived.
We used the SharePoint Migration Tool (SPMT), installed directly on the Windows Server 2016 file server. SPMT on Server 2016 is not as straightforward as Microsoft’s documentation might suggest — it required a number of additional dependencies to even run, and getting it stable took some patience.
Once running, the bulk transfer took 34 hours, scheduled over a weekend to keep disruption to zero. One of SPMT’s most useful features is incremental runs — if the client had needed to pop into the studio mid-migration to do urgent work on a file, we could have re-synced just the changes without restarting from scratch. We never needed to use that capability, but having it there meant the migration didn’t need to be a knife-edge operation.
We were on site for the cutover itself, making sure everything behaved properly once the dust settled — Illustrator opened the right files, the RIP software talked to the printers, and the client could carry on as normal.
Total downtime for the business: none.
What Went Wrong (Because Something Always Does)
Anyone who tells you a migration went perfectly is either lying or didn’t look closely enough. Two issues are worth flagging, because they’re the kind of thing that catches out anyone attempting a similar project.
The 250GB ZIP Problem
OneDrive and SharePoint have file size limits. The current limit is generous — but it’s not unlimited, and a number of the client’s archived project folders had been compressed into single ZIP files of 250GB or more over the years.
Those archives simply could not be uploaded as-is. We had to manually unzip them, restore the underlying folder structure, and migrate the contents normally. This added meaningful time to the project and is the single biggest reason we’d advise any business considering a similar move to audit their archives early. If you have huge ZIPs sitting on your file server, plan for the time it takes to unpack them.
Mapped Drive Shortcuts
The other quieter issue surfaced after the migration. The client had years of shortcuts, scripts, and saved file paths that all pointed to the old mapped network drive — M:\Projects\... style paths.
OneDrive isn’t a mapped network drive in the traditional sense. It’s a synced folder under the user’s profile. So a shortcut that used to work no longer resolves, and any application or document referencing the old M:\ path simply doesn’t find what it’s looking for.
We worked through these one by one, recreating the equivalent shortcuts under the new structure, but it’s a reminder that a file server migration isn’t just about moving the files. It’s about every reference to those files that lives elsewhere — in shortcuts, in document properties, in user habits.
Where the Client Is Now
The measure of a successful migration isn’t whether the technical work was clever. It’s whether the business can do something it couldn’t do before.
The client is now working exactly as they always did — same design tools, same workflows, same outputs — but with one critical difference: they’re no longer tethered to the studio. They can pick up work from home, work on the road, or sit with a client and pull up live files without needing to be in front of the on-prem server.
That mobility was the entire point. The win for them is being able to work the way they want to. The win for us is delivering that without forcing them to change a single thing about how they actually do their job.
What Sets Our Approach Apart
We’ve been working with Microsoft 365 — back when it was still called Office 365 — for around a decade. In that time, we’ve managed tenants ranging from tiny owner-operated businesses up to global admin responsibility on environments with over 70,000 users, and we hold several Microsoft certifications across different parts of the platform.
That experience shapes how we approach migrations like this one. Our approach is, deliberately, the safe one.
We took longer than a “rip and replace” migration would have done. We tested before we committed. We validated that the unusual elements — the RIP software, the design workflows, the file sizes — would behave properly before the client’s livelihood depended on it. We had rollback options at every stage. We were on site for the cutover.
For some clients, that’s not what they want. They want fast, cheap, done. We’re not the right fit for those projects, and that’s fine.
But for an SMB whose business literally depends on the systems being migrated — where a botched cutover means missed print deadlines, lost client work, and a very bad Monday morning — slow and careful is the only sensible approach. We’d rather spend an extra week in planning than spend an extra weekend firefighting.
If You’re Considering a Similar Move
A few honest takeaways for any SMB owner thinking about modernising a setup like this:
You don’t need a crisis to justify the move. Mobility, resilience, and removing the slow drag of ageing infrastructure are reasons enough.
Performance over the internet is genuinely better than most people expect. The instinct that “local will always be faster” is a decade out of date for most use cases.
Plan around your weird stuff. The standard parts of a migration are well-understood. The bits that bite are the specialist software, the archived data, the long-forgotten shortcuts. Audit them early.
Choose a partner who’ll slow down when slowing down matters. The technical work isn’t the hard part. Knowing when not to push the button is what separates a good migration from an expensive lesson.
Thinking about modernising your business IT? We help small businesses move from ageing on-prem systems and hosted email into Microsoft 365 — properly, safely, and with the specific quirks of your industry in mind. Get in touch to talk through what your migration would look like.