Copilot change can no longer be managed as a one-off implementation project 

Today at the Copilot Restart 2026 event, Mikko Kajander and I discussed how the continuous change of Microsoft 365 and Copilot should be managed in organizations. 

The title of our presentation was From Change Management to Continuous Change. 

The title neatly encapsulates the change organizations are in the middle of right now. Microsoft 365 and Copilot are not systems that are deployed once and then left as they are. They are a continuously evolving environment that brings new features, use cases, and opportunities to transform ways of working into organizations. 

Therefore, change management can no longer be carried out as isolated deployment projects. 

Technology changes faster than organizational practices 

A traditional technology project has a beginning and an end. 

A system is selected, deployment is planned, personnel are trained, and the project is closed. After this, operations move into maintenance. 

With Microsoft 365 and Copilot, such a model is no longer sufficient. 

The Microsoft 365 environment evolves continuously. Teams, SharePoint, Office apps, Power Platform, and Copilot receive new features and changes, even hundreds every month. At the same time, users across the organization discover new needs and use cases. 

A single change can be technically minor, yet major from the user's perspective. A button may move, a familiar function might change, or AI might become part of a work phase that was previously done entirely manually. 

Thus, the real challenge is not merely deploying new technology. 

The challenge is how the organization's ways of working, skills, and responsibilities keep pace with the development of technology. 

From a project to a continuous change process 

In our presentation, we introduced a six-step model for managing Microsoft 365 and Copilot changes as a continuous process: 

1. Identify 

2. Assess impact 

3. Prioritize and decide 

4. Prepare 

5. Implement 

6. Measure and learn 

The model forms a continuous process. Change does not end with implementation; rather, the results and user feedback are fed into the next development cycle. 

1. Identify 

A change can stem from a Microsoft service announcement, user needs, a business objective, or a new Copilot use case. 

Organizations need to monitor technological advancements, but not all new features should be rolled out automatically. The first task is to identify which changes are relevant to your own organization. 

2. Assess impact 

Next, assess who the change affects and how significant the impact is. 

A technically minor change can affect a large user base. Conversely, a striking new feature might be relevant to only a limited group. 

In addition to technology, the assessment should take into account at least: 

• user groups 

• work processes 

• information security and permissions 

• data quality and findability 

• required competencies 

• support and communication needs 

• targeted business benefits 

3. Prioritize and decide 

Not all changes can be implemented at once. 

Every change needs an owner, an objective, and a decision. Without clear decision-making, development easily turns into a list of experiments for which no one bears overall responsibility. 

At this stage, you should be able to answer three questions: 

1. What problem are we solving? 

2. What benefit are we targeting? 

3. Who owns the decision and the outcome? 

4. Prepare 

Before rolling out, prepare the necessary settings, guidelines, communication, training, and user support. 

In a Copilot change, preparation can also mean reviewing information management, access rights, or SharePoint structures. AI does not fix unclear information management. It can make its consequences even more visible to users. 

5. Implement 

Implementation does not mean sending out a generic email or holding a one-hour feature training session. 

The new way of working must be connected to the user's actual work context. Useful Copilot use cases differ across finance, sales, HR, and project work. 

Therefore, implementation should take place close to daily work:

• through role-specific examples 

• through practical exercises 

• through shared ground rules 

• supported by managers 

• with the help of peer champions and support services 

6. Measure and learn 

Change should not be evaluated based on how many licenses have been assigned or how many people attended training. 

More essential questions include: 

• Did the way of working change? 

• Was time saved? 

• Did the quality of work improve? 

• Was manual work reduced? 

• Was the new way of working adopted? 

• What do users need next? 

If the way of working did not change, the rollout cannot yet be considered successful. 

Results and feedback are fed back to the start of the process. In this way, change management becomes an ongoing organizational capability rather than a one-off project. 

IT cannot own the change alone 

One of the key topics in our discussion was the division of change management responsibilities across business units. Our presentation featured the M365 service owner or IT, the business owner, the manager, communications and training, and the peer champion or support service. A primary responsibility and a concrete deliverable were defined for each role.   

M365 Service Owner or IT 

IT monitors Microsoft 365 development and assesses the technical impacts of changes. 

The concrete deliverable is a maintained change log and impact assessment. IT also ensures technical governance, security, permissions, and environment compatibility. 

Business Owner 

The business evaluates the priority and targeted benefit of the change. 

Its task is to decide which work processes to invest in and what results to pursue. Without business ownership, Copilot easily remains a disconnected productivity tool. 

Manager 

The manager is responsible for adopting the new way of working within their team. 

This includes setting aside time for practice, leading by example, and monitoring whether the practice becomes rooted in daily routines. Users cannot be expected to continuously reinvent themselves if they are not given time or leadership support. 

Communications and Training 

The role of communications and training is to make the change understandable and learnable. 

Mere information about a new feature is not enough. The user must understand why the change is made, how it affects their work, and what they are expected to do differently. 

Peer Champions and Support Services 

Peer champions and support services bring the change close to the user's daily reality. 

They answer questions, identify practical problems, and collect feedback for the next development cycle. At the same time, they help distinguish technical issues, skill gaps, and unclear work practices from one another. 

Continuous change requires an enduring operating model 

Microsoft 365 and Copilot change can no longer be managed as individual implementation projects. 

An organization needs a continuous model in which changes are: 

• identified 

• assessed 

• prioritized 

• decided upon 

• prepared 

• communicated 

• trained 

• integrated into daily work 

• measured 

• developed based on feedback received 

Copilot adoption is not a one-time technology project. It is an ongoing change process that combines M365 environment development, business goals, work renewal, user skills, and clear accountability.