Plan a cloud move
Map what depends on the system being replaced, agree the destination and access model, and sequence releases with checks between them.
- Dependencies and destination
- Access and ownership decisions
- A release sequence with checks
You may be moving off a file server, preparing for Copilot or trying to turn an early AI trial into useful work. Start with the decision in front of you, then plan the data, access, people and running costs it depends on.
Find your starting point
Choose the situation closest to yours. Each one leads into the planning below.




An organization moving to the cloud starts with foundations and secure access.
This route focuses the work on a destination the business can use and operate.
An organization already on the cloud can begin with the knowledge its teams use every day. A maintained wiki, reusable instructions or a scoped agent may support one useful workflow.
The starting question becomes how existing knowledge and tools can support more useful work.
Teams already trying agents may need custom agents and loops across their tools.
That route focuses on the connections that let a useful workflow continue beyond a single interaction.
A prototype can explore chat interfaces and tools built around institutional knowledge.
This gives the organization a way to examine a proposed experience before committing to its wider use.
A cloud move, better use of existing systems, connected agents and a new prototype answer different needs. Choose the work that matters now; these options are not a ranking of organizations.
A useful plan starts with the work already happening, the foundations already in place and the next outcome that matters.
An organization moving to the cloud starts with foundations and secure access.
This route focuses the work on a destination the business can use and operate.
An organization already on the cloud can begin with the knowledge its teams use every day. A maintained wiki, reusable instructions or a scoped agent may support one useful workflow.
The starting question becomes how existing knowledge and tools can support more useful work.
Teams already trying agents may need custom agents and loops across their tools.
That route focuses on the connections that let a useful workflow continue beyond a single interaction.
A prototype can explore chat interfaces and tools built around institutional knowledge.
This gives the organization a way to examine a proposed experience before committing to its wider use.
A cloud move, better use of existing systems, connected agents and a new prototype answer different needs. Choose the work that matters now; these options are not a ranking of organizations.
A useful plan starts with the work already happening, the foundations already in place and the next outcome that matters.
Move to the cloud, build on the cloud you have, connect custom agents, or prototype a new experience. Each path starts with a different first decision.
The estate includes applications, data and dependencies. Understanding those connections gives the move its real scope.
A plan based on that picture can account for the business work that depends on each system.
People, groups and application identities need an intended access model in the destination.
Planning those assignments early makes the move a chance to clarify responsibility and scope.
Landing zones and operational needs shape the cloud foundation. They provide the context in which the migrated work will run.
The foundation needs an owner and an operating approach as well as a technical destination.
The move is organized into waves, with validation before each release.
That structure creates decision points for confirming the work is ready before more dependencies move.
Ownership, security, cost and operations support the entire modernization plan. They continue across the milestones.
The result is a sequence of decisions the business can review, with the destination and its operation considered together.
The estate includes applications, data and dependencies. Understanding those connections gives the move its real scope.
A plan based on that picture can account for the business work that depends on each system.
People, groups and application identities need an intended access model in the destination.
Planning those assignments early makes the move a chance to clarify responsibility and scope.
Landing zones and operational needs shape the cloud foundation. They provide the context in which the migrated work will run.
The foundation needs an owner and an operating approach as well as a technical destination.
The move is organized into waves, with validation before each release.
That structure creates decision points for confirming the work is ready before more dependencies move.
Ownership, security, cost and operations support the entire modernization plan. They continue across the milestones.
The result is a sequence of decisions the business can review, with the destination and its operation considered together.
A move affects the applications, data and people that depend on the system being replaced. Agree the destination and access model, then release in manageable steps with checks between them.
Data and ownership review covers the content, who is responsible for it and how it is shared.
That context identifies which material belongs in the pilot and which questions need attention first.
People, groups and application access sit alongside the planned Copilot administrative configuration.
Reviewing both connects the intended user experience to the access and settings that support it.
Bring content, access and planned settings into one human readiness decision. Resolve the issues that would make the first pilot unsuitable before widening its audience.
The review gives the pilot a defined starting scope and makes unresolved issues visible to its owner.
Content, identity and configuration contribute to the readiness decision together. A pilot then tests the planned use with reviewed material.
Use the pilot to test the planned work and record what still needs attention. Readiness for that scope is not evidence that every site or workflow is ready.
Data and ownership review covers the content, who is responsible for it and how it is shared.
That context identifies which material belongs in the pilot and which questions need attention first.
People, groups and application access sit alongside the planned Copilot administrative configuration.
Reviewing both connects the intended user experience to the access and settings that support it.
Bring content, access and planned settings into one human readiness decision. Resolve the issues that would make the first pilot unsuitable before widening its audience.
The review gives the pilot a defined starting scope and makes unresolved issues visible to its owner.
Content, identity and configuration contribute to the readiness decision together. A pilot then tests the planned use with reviewed material.
Use the pilot to test the planned work and record what still needs attention. Readiness for that scope is not evidence that every site or workflow is ready.
Pilot Copilot on one useful piece of work before extending it. The pilot exposes gaps in content, access and ownership, and ends in a decision: proceed, fix or wait.
Content and activity provide the evidence for a Purview audit.
The review needs to understand the work taking place before deciding which policies need to change.
Reviewing findings leads to deliberate policy configuration.
This step connects the observed issue to a control that an owner can explain and assess.
Owners validate the configured policy, then continue the review as activity changes.
Their participation connects the control to the intended business use and makes follow-up part of the operating practice.
Revisit content and activity after a policy change to see whether the intended behavior holds. Include Entra identity and group access when investigating a result.
Audit, configuration and validation work best as an ongoing responsibility with a clear owner.
Content and activity provide the evidence for a Purview audit.
The review needs to understand the work taking place before deciding which policies need to change.
Reviewing findings leads to deliberate policy configuration.
This step connects the observed issue to a control that an owner can explain and assess.
Owners validate the configured policy, then continue the review as activity changes.
Their participation connects the control to the intended business use and makes follow-up part of the operating practice.
Revisit content and activity after a policy change to see whether the intended behavior holds. Include Entra identity and group access when investigating a result.
Audit, configuration and validation work best as an ongoing responsibility with a clear owner.
Start with the information the business must protect and how it is used. Review existing labels and policies, test on a pilot, and name the people who will maintain the controls.
Source content and identities belong in the migration inventory. Both affect whether the destination will support the work.
Looking at the files alone leaves important questions about ownership and access unanswered.
The mapping plan connects files to libraries, people to identities and permissions to reviewed groups.
Those choices define what a correct result means before the move is released.
The destination has libraries and groups aligned to the mapping plan. Mapping and validation lead into cutover planning.
The business can then review readiness against an intended result, with the changeover treated as its own decision.
Inventory, mapping, validation and cutover connect the source estate to its planned destination.
Preserve the relationship between content and the people who need it. Agree the source, tools and acceptance checks before committing to a migration schedule.
Source content and identities belong in the migration inventory. Both affect whether the destination will support the work.
Looking at the files alone leaves important questions about ownership and access unanswered.
The mapping plan connects files to libraries, people to identities and permissions to reviewed groups.
Those choices define what a correct result means before the move is released.
The destination has libraries and groups aligned to the mapping plan. Mapping and validation lead into cutover planning.
The business can then review readiness against an intended result, with the changeover treated as its own decision.
Inventory, mapping, validation and cutover connect the source estate to its planned destination.
Preserve the relationship between content and the people who need it. Agree the source, tools and acceptance checks before committing to a migration schedule.
Decide what belongs in the new system and who owns it. Map content, identities and access early, and test them on a representative sample: people and AI both depend on what arrives.
Name the people responsible for preparation, the move and user support afterward. A completed delivery still needs someone to operate the result.
The people plan needs to extend beyond delivery so responsibility remains clear after the change.
Plan the cloud resources around the intended workload, then validate the capacity they supply. Monitor demand in operation so the allocation can change when the work does.
These related decisions help the owner revisit assumptions as the planned workload becomes real operating demand.
Run costs begin with a budget, track change through the move and continue with usage review.
Have the responsible owner revisit the allocation when scope or demand changes. The useful question is whether the resources still fit the work.
People, the cloud estate, capacity and run costs each need attention across the full plan.
Keeping one owner accountable for reviewing those allocations makes trade-offs visible while there is still room to act.
Name the people responsible for preparation, the move and user support afterward. A completed delivery still needs someone to operate the result.
The people plan needs to extend beyond delivery so responsibility remains clear after the change.
Plan the cloud resources around the intended workload, then validate the capacity they supply. Monitor demand in operation so the allocation can change when the work does.
These related decisions help the owner revisit assumptions as the planned workload becomes real operating demand.
Run costs begin with a budget, track change through the move and continue with usage review.
Have the responsible owner revisit the allocation when scope or demand changes. The useful question is whether the resources still fit the work.
People, the cloud estate, capacity and run costs each need attention across the full plan.
Keeping one owner accountable for reviewing those allocations makes trade-offs visible while there is still room to act.
Plan for the people who deliver the work and the people who run it afterward. Where agents are involved, include development, model use and human review, and agree who decides exceptions.
Role-specific guidance explains the task through clear goals and examples.
That gives people a practical starting point tied to the work they are expected to perform.
People practice together using realistic work, supported by the same guidance.
Practice creates an opportunity to find the questions and gaps that a written instruction may miss.
The task becomes part of daily work with support and feedback.
That continued support helps the organization see whether the guidance fits the situations people actually encounter.
Feedback from practical use returns to the role-specific guidance. Learning and operating the task remain connected.
The result is a maintained practice that can improve with the team’s experience, rather than a training event that ends at attendance.
Role-specific guidance explains the task through clear goals and examples.
That gives people a practical starting point tied to the work they are expected to perform.
People practice together using realistic work, supported by the same guidance.
Practice creates an opportunity to find the questions and gaps that a written instruction may miss.
The task becomes part of daily work with support and feedback.
That continued support helps the organization see whether the guidance fits the situations people actually encounter.
Feedback from practical use returns to the role-specific guidance. Learning and operating the task remain connected.
The result is a maintained practice that can improve with the team’s experience, rather than a training event that ends at attendance.
Prepare people for the tasks that change, with examples from their own roles, and agree how you will check that the new way of working is used.
Move to cloud is the opening milestone. It sets the direction for the systems and work the organization wants to change.
The roadmap makes that initial decision part of a wider plan rather than an isolated technical relocation.
Information governance and roles and access define how the destination’s content and identities will be managed.
Resolving those questions helps deployment carry the intended controls into the working environment.
Deploy to cloud and agentic features complete the main route. The quieter branch represents another path through the plan.
The choice of path depends on the organization’s starting point and dependencies; the numbers are milestones, not a delivery timetable.
The roadmap links the move to its content, access, deployment and agentic decisions.
That connected view helps a business owner understand why one decision must be settled before another part of the work proceeds.
Move to cloud is the opening milestone. It sets the direction for the systems and work the organization wants to change.
The roadmap makes that initial decision part of a wider plan rather than an isolated technical relocation.
Information governance and roles and access define how the destination’s content and identities will be managed.
Resolving those questions helps deployment carry the intended controls into the working environment.
Deploy to cloud and agentic features complete the main route. The quieter branch represents another path through the plan.
The choice of path depends on the organization’s starting point and dependencies; the numbers are milestones, not a delivery timetable.
The roadmap links the move to its content, access, deployment and agentic decisions.
That connected view helps a business owner understand why one decision must be settled before another part of the work proceeds.
The plan, its decisions and the knowledge behind them pass to the people who deliver and run the work. Your team takes it forward, with Matt alongside where that helps.
Bring the change you are considering, the deadline and the constraints you already know. We define what needs investigating before the plan is scoped.
Map what depends on the system being replaced, agree the destination and access model, and sequence releases with checks between them.
Choose a first piece of work for Copilot, review the content and access it depends on, and decide what to fix before widening use.
A plan your team can use to make the next decision.
Matt keeps the plan's knowledge and decisions maintained, so planning carries into delivery. Remote first, and in person across Toronto, Mississauga and the Golden Horseshoe when a workshop benefits from it.
Start with the change you are being asked to make.