ICT Field Notes

When I inherited the school IT environment, it was still built around RM Community Connect 4.

For a long time, CC4 had clearly been central to how the school network was managed. It handled a lot of the traditional school IT requirements: users, devices, policies, builds, and the general structure of the environment.

I do not want this post to come across as simply criticising CC4. For many schools, platforms like this made sense. They provided a school-focused way to manage users and computers, especially for IT teams that did not have the time, staff, or in-house experience to build everything from scratch.

The problem for us was that the environment had moved on.

By the time I inherited it, CC4 was no longer just a management platform. It had become part of the technical debt. It affected how easily we could modernise, how confidently we could troubleshoot, and how much control we had over the direction of the environment.

Moving away from it was not about replacing one product for the sake of it. It was about moving towards a more standard Microsoft-based environment that we could understand, document, support, and develop ourselves.

The environment I inherited

The school was heavily Windows and Microsoft-based, but a lot of day-to-day management still revolved around CC4.

That meant the environment was not simply “Active Directory, Group Policy, Windows deployment, and Microsoft 365”. There was an additional RM layer over the top that influenced how devices were built, how users and computers were managed, and how some parts of the network behaved.

One of the challenges with inheriting that kind of environment is working out where standard Microsoft infrastructure ends and the vendor-specific layer begins.

If something behaves unexpectedly, you have to ask:

• Is this standard Active Directory?
• Is this Group Policy?
• Is this a script?
• Is this RM-specific?
• Is this a legacy setting?
• Is this something someone changed years ago and forgot to document?

That made troubleshooting slower than it needed to be.

The environment worked day to day, but it was not as transparent as I wanted it to be.

Why we started looking beyond CC4

The biggest pressure was modernisation.

The school needed to move towards a more current way of managing devices and infrastructure. Windows 10 was approaching end of support, Windows 11 needed planning, and Microsoft 365 and Entra ID were becoming more important to the long-term direction of the environment.

There were also practical day-to-day frustrations.

Software deployment was essentially non-existent through the existing setup. We had already moved to PDQ Deploy for software deployment because we needed a more reliable and direct way to push applications out to devices.

Another major issue was Office. We were effectively being forced to continue using 32-bit Office 2016, which had become a recurring source of freezing and crashing. That was not sustainable long term, especially when the wider direction of the environment was clearly moving towards Microsoft 365, newer Office builds, Windows 11, and more modern endpoint management.

At the same time, RM’s own direction was moving towards CC5.

For us, that created a decision point. We could either continue down the managed platform route, moving from CC4 to CC5, or we could take the opportunity to move towards more standard Microsoft tooling.

The route we chose was to rebuild around the tools we already had or wanted to use:

• Active Directory
• Group Policy
• Microsoft 365
• Entra ID
• MCEM/SCCM
• Windows 11 deployment
• Hyper-V
• Standard Windows Server roles

This was not because CC5 was necessarily the wrong option for every school. It was because, for our environment, moving towards standard Microsoft tooling made more sense.

We wanted more control, more visibility, and less dependency on a school-specific management platform.

Setting up MCEM was the turning point

The first major thing we replaced with our own Microsoft tooling was device deployment and management.

Setting up MCEM/SCCM was a major turning point because it gave us control over a part of the environment that had previously felt too tied to the legacy platform.

In a school, device deployment matters. Machines are rebuilt, moved between rooms, replaced, repurposed, repaired, and prepared for new academic years. If the build process is difficult to understand or difficult to change, the whole environment becomes harder to manage.

With MCEM, the process became much more transparent:

• PXE boot
• Collections
• Task sequences
• Driver packages
• Applications
• Logs
• Boundaries
• Deployment status
• Repeatable build steps

It was not always simple, but it was standard.

If a deployment failed, there were logs to check. If a driver was missing, there was a clear place to fix it. If an application needed adding, it could be packaged and deployed properly. If a task sequence needed changing, it was something we controlled.

That was a big difference.

The move away from CC4 was not only about removing an old system. It was about building a deployment process that could support Windows 11, newer Office versions, and the long-term direction of the environment.

The cutover was a real project, not a small background change

Moving away from CC4 was not something we did quietly in the background over months.

It was removed in one main project.

That made the change significant. It was not just a case of swapping one small component. CC4 had influenced enough of the environment that removing it and moving to our own management approach created a noticeable shift.

The move brought across some problems at first. That was not unexpected. When you change something that has been central to how the environment works, there are always going to be issues to work through.

Some of those issues were technical. Some were operational. Some were simply the result of moving from one way of doing things to another.

However, within about a week, things had calmed down again.

That is probably one of the more honest parts of the project. It was not completely seamless, but it was manageable. The short-term disruption was worth it because it moved the environment onto a path that was easier to support, easier to modernise, and easier to understand.

Windows 10 end of support changed the urgency

Windows 10 end of support created a hard deadline.

Once it was clear that Windows 10 22H2 would be the final version of Windows 10, with support ending in October 2025, the question became more urgent. A legacy school network built around older assumptions could not just sit unchanged forever.

Windows 11 readiness was not just about whether the hardware could run Windows 11. It was also about whether the management approach was ready for Windows 11.

That meant thinking about:

• How devices would be built
• How drivers would be managed
• How policies would apply
• How updates would be handled
• How staff devices would be managed
• How Microsoft 365 and Entra ID would fit in
• How much of the existing setup was still needed

For us, that made CC4 feel less like a long-term platform and more like something we needed to move beyond.

The problem with vendor-shaped environments

One of the main lessons I took from CC4 is that vendor-shaped environments can be very convenient at first, but difficult to modernise later.

A managed platform can reduce complexity when it is introduced. It gives schools a structure, a standard way of doing things, and support from a supplier that understands education.

But over time, that same structure can become restrictive.

The more your environment depends on one platform’s way of doing things, the harder it becomes to separate what is genuinely required from what is just inherited behaviour.

That matters when you want to make changes.

If you want to redesign Group Policy, change your deployment method, introduce SCCM, move towards Entra ID, or simplify your server estate, you need to understand the underlying infrastructure properly.

I wanted the environment to be manageable by someone with standard Windows Server, Active Directory, Microsoft 365, and endpoint management knowledge. I did not want every problem to require understanding a vendor-specific school platform first.

Moving towards standard Microsoft tooling

The direction we moved in was fairly clear: simplify the environment and build around standard Microsoft tooling.

That did not mean ripping everything out overnight. It meant gradually replacing the dependency on CC4 with systems and processes we could own directly.

Some of the key areas were:

• Moving towards SCCM/MCEM for Windows deployment
• Building our own Windows 11 task sequences
• Cleaning up Active Directory and Group Policy
• Planning for Entra ID and hybrid join
• Preparing for OneDrive Known Folder Move
• Moving infrastructure to Hyper-V
• Rebuilding old servers where it made sense
• Improving documentation and asset tracking

The goal was not just to remove CC4. The goal was to make the environment easier to understand and easier to change.

A standard Microsoft-based setup gave us a clearer path for future work. If something needed changing, I could look at AD, GPO, SCCM, Entra, Intune, Windows Server, or Microsoft 365 directly instead of first having to work out how CC4 fitted into the picture.

Group Policy and Active Directory cleanup

Another major part of moving away from CC4 was gaining confidence in Active Directory and Group Policy.

When an environment has been managed through a platform for years, there can be a lot of inherited structure: old OUs, old policies, old scripts, old assumptions, and settings that nobody wants to touch because nobody is completely sure what they do.

Cleaning that up takes time.

It is not as simple as deleting everything that looks old. Some legacy settings may still be important. Some may only apply to one department or one type of device. Some may have been created to solve a very specific issue years ago.

The safer approach is to understand, document, test, disable carefully, and only remove things once you are confident they are not needed.

Moving away from CC4 gave us the opportunity to think about what our AD and GPO structure should look like, rather than simply accepting what had accumulated over time.

Why we did not just move to CC5

CC5 was the obvious vendor route.

For some schools, moving from CC4 to CC5 may be the right decision. It keeps them within the RM ecosystem and gives them a supported path forward.

For us, though, the question was not just “what replaces CC4?” It was “what kind of environment do we want to manage in the future?”

RM licensing and support considerations were a nice benefit in the decision, but they were not the main reason. The main reason was modernisation.

We were already heavily Microsoft-based. We were moving towards Microsoft 365, Entra ID, Windows 11, MCEM, and a more standard Windows Server environment. Continuing with a school-specific management platform would have kept us dependent on a particular way of working.

Moving to standard tooling gave us more control and made the environment easier to align with the skills and technologies we wanted to build around.

That does not mean CC5 is wrong. It just means it was not the direction I wanted for this environment.

What improved after moving away

The biggest improvement was visibility.

The environment became easier to reason about because more of it was based on standard components:

• Active Directory for identity
• Group Policy for on-premises policy
• SCCM/MCEM for deployment
• Microsoft 365 and Entra ID for cloud identity and services
• Hyper-V for virtualisation
• Windows Server roles that could be documented and managed directly

That made troubleshooting easier.

It also made future projects easier. Once the environment was less tied to CC4, it was easier to plan Windows 11 deployment, think about hybrid join, clean up Group Policy, standardise builds, and improve documentation.

The environment also felt more like something we owned.

That is hard to measure, but it matters. When you understand how the moving parts fit together, you can make better decisions and take more responsibility for the platform.

What was difficult

Moving away from a platform like CC4 is not just a technical task.

It is also a discovery exercise.

You have to understand what the platform is doing, what the school still depends on, what can be replaced, and what needs to be rebuilt in a different way.

The difficult parts were not always dramatic technical failures. Often, the difficulty was uncertainty.

Questions like:

• Is this setting still needed?
• What happens if this policy stops applying?
• Which devices still depend on this process?
• Is this server still used?
• Is this behaviour RM-specific or standard Windows?
• Has this been documented anywhere?
• Is there a safer way to replace this?

It is easy to underestimate how much operational knowledge is hidden inside a platform that has been used for years.

Lessons learned

The biggest lesson is that “working” and “healthy” are not the same thing.

The CC4 environment worked. Users could log on. Devices could be used. The school functioned.

But it was not where I wanted the environment to be long term.

A healthy environment should be understandable, supportable, documented, and able to change. It should not depend too heavily on one platform, one supplier, or one person’s memory.

For other school IT teams looking at a similar decision, I would think about:

• Whether the current platform still fits the school’s direction
• How much vendor dependency exists
• Whether the environment can be supported using standard skills
• How Windows 11 and Microsoft 365 fit into the plan
• Whether device deployment is transparent and repeatable
• Whether Group Policy and AD are understood
• Whether the migration path reduces or increases complexity
• What the environment should look like in five years

The answer will not be the same for every school.

Some schools may be better staying with a managed platform. Others may benefit from moving towards standard tooling. The important thing is making that decision deliberately rather than simply following the default upgrade path.

Final thoughts

Moving away from RM CC4 was not about blaming a product for every problem in the environment.

It was about recognising that the environment had outgrown the way it was being managed.

CC4 may have made sense historically, but for us it had become part of the technical debt. It made modernisation harder, added another layer to troubleshooting, and did not fit the direction we wanted to take.

By moving towards standard Microsoft tooling, we gained more visibility, more control, and a clearer path for future projects.

The goal was not to make the environment more complicated. It was the opposite.

The goal was to make it understandable, supportable, and easier to improve.