Know what you are movingAgree who needs accessDesign a staged transitionLeave time for adoption
Know what you are moving
Inventory the data, accounts and applications in scope. Separate active material from duplicates and outdated content, and identify dependencies that may not be obvious from a folder list.
Agree who needs access
Map permissions to working roles and confirm ownership of shared information. Use the move as a chance to make access intentional rather than carrying every historical exception forward.
Design a staged transition
Choose a representative pilot group, define how success will be checked and document a fallback approach. Communicate what changes, when it changes and where people can get help.
Leave time for adoption
The project continues after migration. Provide simple guidance, collect questions and review whether the new structure supports daily work. Address confusion while the change is still fresh.
Use ownership to resolve difficult decisions
Moving information often exposes questions that have remained unanswered for years: who owns a shared folder, who can approve access and whether an archive still has a business purpose. Assign an owner to resolve each question rather than carrying the ambiguity into the new platform.
The project team should not invent retention requirements. Those requirements need input from the organization and, where necessary, its legal or compliance advisers.
Choose a representative pilot group
The pilot should reflect more than the most confident users. Include people with different roles, permissions and working patterns. Ask them to complete ordinary tasks and report where the new structure is confusing or incomplete.
Document the findings, decisions and changes before expanding the rollout. A pilot is useful because it creates a controlled opportunity to learn, not because it guarantees that every later issue has been eliminated.
Write the cutover decision in advance
Define who decides that the migration can proceed and what evidence they need. Include required checks, unresolved issues, user communications and the fallback conditions. This makes the decision less dependent on pressure at the end of a busy project day.
A fallback approach should be realistic about changes made after cutover. It is not enough to say that the business can simply return to the old system if new information has already been created elsewhere.
Measure adoption through real work
After the migration, review common questions, access issues and workflows that still send people back to old habits. Update the guidance to address what users actually encounter.
A useful review asks whether information is easier to find, ownership is clearer and collaboration follows the agreed structure. Those observations are more meaningful than treating the number of migrated files as the only measure of completion.
The next step
Bring the business problem, the systems involved and the decisions you need to make into one conversation.
Discuss your next project ↗