The Time to Move to a Pure Cloud Is Now

Previously, SharePoint Online did not strictly enforce CSP restrictions that would affect customizations using inline scripts or external script references. Microsoft is now aligning SharePoint with modern web security practices and is gradually rolling out a stricter Content Security Policy across SharePoint Online environments. This is a good thing. With a properly configured CSP, the browser refuses to execute injected scripts originating from untrusted sources.

Initially, SharePoint’s new CSP operated only in reporting mode, logging violations without enforcing them. However, on March 1, 2026, Microsoft began switching SharePoint Online tenants from reporting-only mode to full enforcement, which in practice blocks the execution of all scripts that violate the new CSP.

While Microsoft’s goal is purely to improve the security of SharePoint Online environments, the change has come as an unpleasant surprise to many. Organizations that built their customizations on external script references and inline scripts—often added via the open-source Script Editor web part—have been caught off guard. The policy prevents such scripts from running and therefore breaks these customizations entirely.

If you work in an organization that has just realized that the new Content Security Policy has broken its SharePoint Online customizations, this blog post is for you. We’ll walk through solution options that can be implemented quickly in the short term and properly in the long term.

As with many good practices, the first step is to understand what you actually own and how it has been implemented. This sounds simple, but in even moderately sized environments, sufficiently detailed information about applications or services is rarely available in a single place—even though, in an ideal situation, the answer should be found in a Configuration Management Database (CMDB).

The first concrete step is therefore a current-state assessment: what services, systems, and dependencies currently exist in the organization? It is particularly important to identify components that are tied to on‑premises services, such as Active Directory (AD), file servers (applications may still store files locally), or printing solutions.

AD is often integrated with surprisingly many services: certificate-based authentication for wireless networks, access control systems, and, of course, applications. When listing applications, a large portion can often be ruled out immediately—typically, applications that run purely on workstations do not require AD, nor do applications that use their own authentication. Even so, there is usually something left.

A cloud transition cannot be done all at once—it must be phased. A modular approach, where the transition is divided into domains such as identity management, file services, applications, and networking, makes the project more manageable and reduces risk.

Some of the required changes may emerge as by-products of ongoing or already scheduled projects. The key is to steer all projects toward the same end goal: no new on‑premises dependencies should be created; instead, existing ones should be dismantled within each domain.

Each domain must have clear objectives, a timeline, and designated owners. This enables parallel progress across teams and ensures that each area advances as planned. For example, identity management migration can be carried out while print services are being moved to the cloud. Microsoft offers a wide range of lesser-known services within its portfolio that support cloud adoption and has also begun introducing new tools specifically designed to enable a full cloud transition.

A cloud transition also changes the roles of services

For example, the importance of networking services grows when some services previously delivered via Windows environments are moved to network devices. Some once-obvious services may become unnecessary altogether. For instance, why maintain VPN services if there is no internal network to connect to? This shift requires a new way of thinking about ICT organization, and in some cases, it makes sense to transfer responsibility for certain services from one team to another.

It is also essential to document dependencies between domains. If one service requires another domain to be completed before it can be moved to the cloud, this must be reflected in the schedule. A well-designed project structure enables flexible progress and the ability to respond to changing circumstances.

A cloud transition is not merely a technical implementation—it is a project that requires a clear objective, strongly supported by ICT leadership, and driven step by step toward that goal. A roadmap that outlines the different phases of the transition and their timelines serves as the backbone of the project. It helps visualize the overall picture and ensures that all critical domains progress as planned.

Once the transition has been broken down into manageable components and scheduled, each domain must be assigned an owner responsible for progress, decision-making, and reporting. Additionally, the entire project must have a clear owner—a person or group that holds overall accountability and ensures the transition aligns with strategic objectives.

While a cloud transition delivers savings in the long term, the initial phase inevitably involves some costs before savings are realized. Budgeting must take into account not only investments in the new environment, but also what is being retired—and what it costs to retire it.

A pure cloud environment is not just a technical change—it is an opportunity to renew the operating model of the entire organization, not just ICT. It brings agility, scalability, and the ability to respond quickly to changing business needs. Now is the right time to start planning and to phase the steps that will make the transition a reality.

Context& as a company was born in the cloud. In the early days, we often had to fight attitudes and preconceptions about whether the cloud could be trusted and whether it was safe to place anything business-critical there. Today, it is widely understood that local environments simply cannot deliver the same level of functionality and security that is readily available in the cloud.

We have experienced almost everything in cloud transitions—from migrating individual workloads to moving entire organizations 100% to the cloud. Shall we help you take the next step into a fully cloud-based future?