01
Inventory
Data volume, file counts, permissions export, applications with hard-coded paths, scheduled tasks, integrations and connected devices.
Data Migration
Move your data without losing a weekend
Migrations fail on the things nobody inventoried: the permission that did not carry, the application still pointing at the old server name, the mailbox rule that vanished. We work from checklists rather than memory, sync in the background, and keep the old environment alive until the new one has proven itself.
🛡 Checklist Driven⏱ Rollback Available💰 Background Sync First★ Verified After Cutover
Method
Migrations fail in the discovery phase, not the copy phase
Copying data is the easy part and it is what people worry about. The problems come from everything attached to the data: permissions, application connection strings, mapped drives in login scripts, scheduled tasks, printer paths and the system that references the old server by name in a configuration file nobody has opened since installation.
Our discovery is deliberately exhaustive. We inventory data volume and file counts, because a million small files behaves nothing like the same volume in large files. We export effective permissions so they can be verified afterwards rather than assumed. We find every application with a hard-coded path or server name, every scheduled task, every login script, every device relaying mail, and every integration nobody mentioned in the kickoff meeting.
Sync first, cut over second
We copy the bulk of the data well before the cutover window, then run repeated incremental syncs so the final delta at switchover is small. That turns a cutover from an overnight endurance test into a short, controlled window. It also gives us a real measurement of transfer rate, which is what makes the schedule honest rather than optimistic.
Long file paths, unsupported characters, open files locked by an application, and permission structures that do not translate cleanly all surface during those early syncs. Finding them three weeks out is a task. Finding them at 11pm on cutover night is a problem.
The cutover window and the rollback
Every cutover gets a written runbook with the sequence, the owner of each step, the verification test for each step and the abort criteria. We decide in advance what would make us roll back, so that decision is not made under pressure at 2am by someone who has been working for fourteen hours.
The old environment stays intact and available, in a controlled read-only state where appropriate, until the new one has run clean for a couple of weeks. Decommissioning on the Monday after cutover saves nothing and removes your safety net exactly when you are most likely to need it.
Different migrations have different traps. Mailbox moves stumble on delegate permissions, mailbox rules, shared calendars and mobile device reconfiguration. File share moves stumble on permissions and path length. QuickBooks company file moves need version and multi-user considerations handled carefully, with the hosting mode and database server manager configured correctly on the new host. Our QuickBooks support page covers that in detail. Server to cloud moves stumble on latency assumptions that were never tested.
Verification is the last step and it is not optional. We compare file and folder counts, spot check content, verify effective permissions against the pre-migration export, confirm every application connects, test printing, and have real users open real documents before we call it done. Related work sits on cloud solutions, Exchange and server support, with platform detail at microsoft365.orcait.io.
Nothing is deleted on cutover day
The source environment stays available until the destination has run clean for two weeks. A migration is not finished when the data lands, it is finished when nobody has needed the old copy.
Zero-Loss Checklist
Six checks that prevent the usual disasters
These are the items that, when skipped, generate the call three days after cutover.
Export permissions before you move
Effective access is captured up front so it can be verified afterwards. Reconstructing intended permissions from memory after the fact never goes well.
Find hard-coded paths
Applications, scripts, scheduled tasks and shortcuts referencing the old server by name. Each one is found, listed and updated deliberately.
Measure the real transfer rate
An early bulk sync tells you how long the final delta will take. Schedules built on theoretical bandwidth are how cutover windows overrun.
Handle long paths and odd characters
Deep folder trees and unsupported characters break cloud migrations reliably. They get identified and remediated weeks before cutover.
Reconcile counts after the move
File and folder counts compared source to destination, with spot checks on content. A migration that lost data quietly is worse than one that failed loudly.
Test with real users
Actual staff opening actual documents, printing, and using their applications before we declare success. Engineers testing their own work miss things.
How It Works
Four phases of a migration
02
Seed and sync
Bulk copy well ahead of cutover, then repeated incremental syncs so the final delta is small and the timing is measured, not guessed.
03
Cut over
A written runbook with sequence, owners, verification tests and abort criteria, executed in an agreed window with the team available.
04
Verify and settle
Counts reconciled, permissions checked against the export, applications and printing tested, then two weeks of close support before decommissioning.
Fixed price, defined window
You get a scope, a schedule and a number before the project starts. Genuine scope changes are agreed in writing, not discovered later.
Data migration questions
How long will our migration take?
It depends far more on file count and internet speed than on total size. A typical small business file share move runs one to three weeks including preparation and background sync, with a short cutover window. Mailbox migrations are usually two to three weeks end to end. We measure real transfer rates during the seed sync rather than estimating.
Will we be down during the migration?
Only during the cutover window, which is scheduled outside business hours and is short because the bulk of the data moved beforehand. Most clients experience a weekend switchover and normal working on Monday, with us available for the questions that Monday always produces.
What is the biggest risk in a migration?
Incomplete discovery. Almost every failed migration we are called in to rescue lost something that was never inventoried: a permission set, an application connection, a scheduled export, a device relaying mail. The copying itself rarely fails; the things attached to the data do.
Do permissions carry across automatically?
Partially, and the gaps matter. Moving between file systems generally preserves standard permissions, but moving from a file share to SharePoint changes the model entirely and requires deliberate mapping. We export effective permissions before the move and verify them against the destination afterwards.
Can you migrate our QuickBooks company file?
Yes. It needs care around version compatibility, multi-user hosting mode and the database server manager configuration on the new host. We move the file, configure hosting correctly, verify the file opens cleanly in multi-user mode and confirm every workstation connects before closing the project.
What happens to the old server?
It stays intact and available, often in a read-only state, for at least two weeks after cutover. Once the new environment has proven itself we decommission it properly, including a documented data wipe if it is being disposed of or recycled.
Can you migrate us if we are not an ongoing client?
Yes. Migrations are commonly delivered as standalone fixed-price projects, and plenty of businesses meet us that way first. There is no requirement to sign up for a managed plan, and we will hand over clean documentation when the project closes.
Do you do migrations outside Arizona?
Yes, remotely, across all 50 states. Discovery, sync, cutover and verification are all done over the network. If the project requires physical work such as installing new hardware or decommissioning equipment, that needs local hands and we will say so during scoping.
Get a migration plan, not a guess
Full inventory, measured transfer rates, a written runbook and a rollback path.
Talk to Your Pod
Planning a move you cannot afford to get wrong?
Tell us what is moving and where it is going. We will inventory it, build a cutover plan with a rollback path, and quote the project as a fixed price with a defined window.
(602) 677-0779Family owned in Gilbert, AZ since 2015 · onsite across the Phoenix metro · remote support nationwide · never outsourced
Same-day response
No long contracts
Flat, honest pricing
Five-star service
Get your free IT consultation
A few details and your pod gets right back to you, usually the same business day.