What this covers
- File server, NAS and SAN migrations with permissions and ACLs intact
- Database platform and version migrations, including cross-vendor moves
- Application data migrations with field-level mapping and reconciliation
- Tenant-to-tenant and on-prem to cloud data moves
- Pilot-measured throughput so the cutover window is realistic
- Row and byte-level validation reporting before sign-off
Migrations fail in the details, not the concept
Nobody struggles with the idea of copying data from one place to another. Projects go sideways on the parts that don’t fit on a slide: the share with 40 million small files, the ACLs that reference a domain that was decommissioned in 2014, the application that hard-codes a UNC path, the legal hold nobody mentioned, the table whose “unique” key isn’t.
I’ve been doing this work since 2010, and the approach hasn’t changed much because it keeps working: find the ugly parts early, measure instead of estimate, and never move anything without a way back.
What an engagement looks like
Inventory and profiling. Before a plan exists, I profile what’s actually there — volumes, file counts, size distribution, open handles, permission complexity, orphaned SIDs, encoding problems, and the dependencies that will break when the path changes. For databases and applications, that means schema, row counts, referential integrity, and the reports people quietly run against the back end.
Mapping and design. Source-to-target mapping down to the field or share level, including what gets transformed, what gets dropped, and who signed off on dropping it. This document is what everyone argues over before the cutover, which is the whole point of writing it.
Pilot. A representative batch moved end to end, against production-like data, on your storage and your network. That’s where the schedule comes from. A vendor throughput number is not a schedule.
Seeding and delta passes. Bulk copy well ahead of the window, then repeated incremental passes so the final sync moves hours of change instead of terabytes.
Cutover. A timed runbook with named owners, validation gates, and an explicit go/no-go at each gate. Everyone knows what “done” looks like and what triggers a rollback.
Reconciliation. Counts, checksums, spot restores, permission comparisons, and application-level smoke tests — delivered as a report, not a verbal “looks good.”
Common projects
- Consolidating aging file servers onto a modern NAS, DFS namespace, or Azure Files
- SAN and NAS replacements where the array is going end-of-support
- Merging or splitting environments after an acquisition or divestiture
- Moving line-of-business application data to a new platform or vendor
- Lifting on-premises data into cloud storage without breaking the applications on top
- Home drive and departmental share cleanup and re-homing
What you get
A written migration plan, a tested runbook, the scripts used to execute it, reconciliation evidence, and documentation your team keeps. If your internal staff want to run the next wave themselves, that’s a successful outcome, not lost revenue.
Common questions
How much downtime should we plan for?
It depends on change rate, not total size. With seeding and delta passes, most file and storage migrations cut over in a maintenance window measured in hours. The pilot tells us the real number before you commit to a date.
Can you work with our existing tooling and vendors?
Yes. If you already own DataDobi, XCP, a storage vendor's migration service, or a partner doing part of the work, I'll work inside that rather than push a replacement.
Do you do the work, or just advise?
Both, depending on what you need. I'm equally comfortable writing the plan for your team to execute or running the cutover myself at 2 a.m. on a Saturday.
How do you prove the migration was complete?
Reconciliation evidence: file and row counts, checksum sampling, permission comparison reports, and application smoke tests, all captured before sign-off.