How One! International School Tested a New Platform Before a 1,000+ User Rollout

Launching a new digital platform in a large school always carries some risk. When thousands of people will rely on the system, an unprepared rollout can create serious problems for administrators, teachers and parents.

One! International School has more than 1,000 users. Before introducing a new platform across the whole school, the team decided to begin with a pilot. We spoke to Alexander Frolov, who led the implementation project on the school’s side, to find out how the pilot was organised, what the team tested and what they learned before moving to a full rollout.

Why the school started looking for a new platform

By the time the pilot began, the school was already using an electronic gradebook. However, the existing system did not give the leadership team the level of access to data they needed.

Information had to be collected from several sources. Some data could be exported from the gradebook, while other information had to be added manually. This work was carried out by regular school staff rather than dedicated analysts, which meant the data was fragmented, difficult to structure and time-consuming to process.

For the school, this had become a significant problem. If management information arrives one or two months late, important decisions may also be delayed. To manage the school effectively, the leadership team wanted to be able to see changes at least on a weekly basis.

The requirement was therefore clear: the school needed a system that could bring key information together, provide a more accurate picture of what was happening and make management reporting faster and easier.

Why the school started with a pilot

Although the platform looked like a strong fit, the team decided not to introduce it across the entire school immediately. For a project of this scale, a pilot was seen as an essential part of implementation rather than simply an additional stage.

As Alexander Frolov explains:

“I have worked on more than ten system implementation projects, and without a pilot it is almost impossible. You need to see how the system works in practice, how data is created, where it appears and which processes can actually be automated.”

The pilot had several objectives:

• test how easy the system was for teachers, students and parents to use;
• understand what data the platform could provide;
• test academic reporting;
• prepare a clear plan for the full implementation.

It also helped create a group of experienced users who could later support colleagues when the platform was introduced more widely.

Preparing for the pilot

One of the most time-consuming parts of the project was preparing the data. Even when a platform supports automated imports, the information still needs to be collected, checked and structured beforehand.

The system was opened in mid-February, but testing could not begin immediately. The school first had to prepare a substantial amount of information for upload, including user lists, class structures and the timetable.

Once this data had been imported, the team configured the school structure within the platform. Only then could full testing begin.

How the pilot was organised

The testing period lasted around two months. The pilot included:

• 3 school classes;
• 3 kindergarten groups;
• around 30 members of staff.

The participants were selected deliberately.

Year 5 classes were included because their form tutors were among the most confident users. They were able to learn the system quickly and support colleagues during the pilot.

Older year groups were selected to test more complex timetable structures, including combined teaching groups and classes divided into smaller groups. This allowed the team to see how the platform performed in less straightforward scenarios.

The kindergarten was also included so the school could assess how well the system supported communication with parents in a different educational setting.

How responsibilities were divided

The pilot was managed by a relatively small internal team. Alexander Frolov led the project and coordinated the implementation, supported by academic coordinators, deputy heads and the form tutors of the participating classes.

“The academic coordinators were mainly responsible for the operational setup: creating timetables, checking class and group structures, and testing different scenarios. Some members of staff also used the system as parents so they could see what the experience looked like from the other side.”

What the school tested

The team focused on several key areas during the pilot.

First, they looked at usability for the main groups of users: teachers, students and parents. The interface needed to feel familiar enough that the transition would not become an additional burden. Some change was expected, but the team wanted the core processes to remain intuitive — whether teachers were planning lessons and recording marks or parents were looking for homework and information about their child.

Second, the team assessed the quality of the data available through the system and whether it could support management analysis.

Academic reports were another major focus. Previously, these had been prepared manually: data was entered into Google Sheets and form tutors then created individual PDF reports for each student. The pilot made it possible to compare the amount of time required and assess how much of this process could be simplified.

What proved most difficult

The biggest challenge was not the technology itself, but user resistance.

As Alexander puts it:

“People generally do not like systems that introduce more control. Any new system creates some resistance, so it is important to explain why the change is being made.”

For teachers, the rollout meant changing familiar ways of working. The project therefore depended not only on configuring the platform, but also on managing expectations and helping users understand the reason for the change.

The strongest argument was practical: the new system could reduce the amount of manual work. As users began to see that benefit for themselves, resistance gradually became easier to manage.

When the school knew it was ready to scale

By the end of the pilot, the team had enough evidence to move forward with a full-school rollout.

The platform gave the school a clearer view of subjects, teachers and assessment, while providing more regular access to up-to-date information for decision-making.

It also reduced the time required to prepare reports and the school’s reliance on manual data collection — a process that had previously caused delays and made it harder to maintain consistent information.

For the leadership team, this meant faster access to reliable information and a stronger foundation for day-to-day management decisions.

One reaction from a form tutor was particularly telling. After seeing how an academic report was generated, she asked:

“Is that it? Is it really that simple?”

For the project team, this was another sign that the system was genuinely simplifying everyday processes rather than simply replacing one form of administration with another.

The school’s main takeaway

Implementing a new system is not a single event. It is a process that needs preparation, testing and time.

The pilot showed that introducing a platform across a large school without testing it first would create unnecessary risk. There are simply too many users, processes and data flows to switch everything on at once and expect the system to work smoothly from day one.

A pilot gives the school an opportunity to work through these challenges on a smaller scale: to understand how the system behaves in real conditions, identify where difficulties appear and establish how the implementation team should work together.

As Alexander explains:

“If you are implementing a system across the whole school, you have to expect some chaos at the beginning. The important thing is to make that chaos manageable.”

That is ultimately what a well-designed pilot provides: a controlled environment in which the school can test its assumptions, define responsibilities and prepare users before the full rollout begins.