File and document migration
Your files arrive where they should, with access checked before sign-off.
Move the agreed files, test user access and compare the destination with the original inventory. Record differences and any issues that need an owner.
- What you get
- The agreed files in their destination, with access checks and a source-to-destination reconciliation record.
- How it starts
- A free scope call. The price is fixed in writing before anyone is given access.
- When it is done
- File counts and access are checked; path and transfer exceptions are resolved or explicitly accepted and recorded.
Illustrative sample · constructed example
A path exception needs an action, not a green total.
Reconciliation excerpt · constructed project folder
Selected check
Has the path exception been corrected and the destination checked?
| Record | Evidence or responsibility | Sample review |
|---|---|---|
| Source item | Projects / Sample project / Drawing register.pdf | Path exception open |
| Destination | SharePoint / Projects / Drawing register.pdf | Transfer awaiting correction |
| Access | Project member allowed; unrelated pilot user denied. | Test pending |
| Existing links | Keep the old-to-new path and links needing an update. | Owner review required |
This is one constructed item. No total migrated, success percentage or client file is represented.
- Evidence
- The source path needs an approved technical rename before transfer.
- Decision
- Keep the exception open
- Next action
- Owner approves the rename and identifies links that need updating.
Constructed row using the documented reconciliation method. It is not a recovered client file or an aggregate success rate.
The related record on the Results page is kept separate from this sample, with its own limits stated beside it.
Inspect the related recordOpen the complete illustrative document to inspect its fields and print a copy.
Open the sample documentWhy now
The work starts here.
Files have to come off a file server, a NAS, Google Drive or Dropbox, because the hardware is going, the contract is ending, or the team cannot work from it any more.
Scope at a glance
- Permissions agreed in writing first
- Checked file by file before sign-off
- You decide what is left behind
If nobody acts
What waiting costs
Permissions that do not come across land in one of two places, and both are expensive: people who cannot open the files they need on Monday, or files opened by people who were not meant to have them.
A file that was not counted before the old server is switched off can only be got back by paying to keep that server running past the date it was meant to go.
File names and paths that the old system allowed and the new one does not fail quietly during the move, so the gap is found by whoever needed the file, not by whoever ran the move.
Moving everything because nobody decided what to leave behind means paying to store years of material no one will open again, every month, from now on.
Check your own environment
Sounds like you?
- The file server or NAS is out of warranty, or the storage contract is ending
- People keep local copies because the shared drive is slow or hard to reach
- Folder permissions were set up by someone who has left
- Nobody can say how much of the share anyone has opened in the last two years
Save yourself the call
Not for you if
- The files are already in SharePoint or OneDrive and the real problem is how they are organized
- It is one folder that one person can copy across in an afternoon
- The move is between two Microsoft 365 tenants, which is its own job
The work
What is different when we hand over
What is in scope is counted before anything moves, and each folder gets a named destination.
Permissions are mapped as they are today, and the target list of who can open what is agreed in writing before the move.
File names and paths the destination will not accept are found first and fixed, rather than discovered as failures mid-move.
The move runs in dated groups, and each group is checked before the next one starts.
The destination is checked against the source file by file, and every gap is closed or given an owner.
Acceptance
Checks before handover
Every folder on the agreed list has arrived at its named destination
Access is tested against the agreed list of who should be able to open what
The agreed source and destination counts are reconciled, exceptions are recorded, and technical path or filename changes are listed for approval
A fair question
Can we not just drag the folders into OneDrive?
For a small share, yes. It goes wrong at scale in ways that are quiet: permissions do not come with the files, so people either lose access on Monday or gain access they should not have, and file names and paths the old system allowed will fail on the way in without announcing it. Those failures get found by whoever needed the file, not by whoever ran the copy.
Price and calendar
Scope, price and project calendar
Engagement price
Price fixed after a short scope call.
The price is agreed in writing before any work starts and before anyone is given access. The call itself costs nothing. What moves the number:
What determines the scope
- How much data is moving, and how many shares or sites it comes from
- Whether permissions carry across or have to be rebuilt at the destination
- How much has to be sorted, archived or left behind before the move
- Whether people keep working in the files while the move runs
Delivery calendar
The calendar is set once the data, the dependencies and the cutover requirements have been checked, then fixed in writing before the move begins.
How engagements workScope & responsibilities
What is and is not included
The exclusions, what we need from you, how change is staged and reversed, and what is handed over at the end.
Exclusions
- Licenses needed to run the move
- Business content sorting or reorganization, unless separately agreed. Necessary technical path/name corrections is identified and approved within the migration scope
- Repairing a source system that is already failing
- Help desk and staff support
What we need from you
- Decide what moves, what gets archived, and what is left behind
- Confirm who should be able to open what at the destination
- Give administrator access to the source and the destination
- Tell your staff when the files move and support them afterwards
Change and rollback method
- Folders move in dated groups, and a group is not started until the one before it checks out.
- The conditions that stop the move are agreed before the first file moves, and they name conditions rather than intentions.
- The source stays readable until the check sheet is signed off, so a gap found late still has somewhere to be recovered from.
What you keep at handover
- A System guide: the configuration as delivered, the checks that were run and the unresolved list
- The counted list of everything that moved
- The permissions map, before and after
- The list of names and paths that had to be changed to survive the move
- The agreed conditions for stopping
- The check sheet proving source and destination match
Access, acceptance and support arrangements
How you know the work is good
Judge it by what you can inspect.
The method is written down, the sample records open and the demo can be broken on purpose. Read it the way your technical owner would.
- 01How a project runs
A first conversation, free. An agreed scope with a named technical lead in the proposal. The price fixed in writing before we are given access. Checks before handover.
How we work- 02What is checked
Release checks, access test matrices and ownership maps. Constructed inspection records on the service pages show the standard before you buy.
See sample deliverables- 03What you keep
A System guide: what was agreed, what changed, what was tested and what remains open. With it, the scripts and check results behind the work.
Next step
Start with a free scope call.
Tell us what needs to change, what must keep working and the deadline. The call is free, and the price is fixed in writing before anyone is given access.
Price the file moveOr write to [email protected]