Modernisation Without Compromise | iSAMS by IRIS

In chapter one, I said the next iSAMS isn't a launch campaign. It's a product-transparency programme. That earned a fair bit of goodwill, and it also earned a version of the same question, asked in emails, at conferences, and once over coffee at a partner event: “Modern usually means simpler. What are we actually losing?”

It's a fair question. It deserves a straight answer, not a marketing one.

So here it is. We are not simplifying iSAMS. We're not trimming features, hiding functionality behind extra clicks, or trading configurability for a cleaner-looking dashboard. If that's what “modernisation” meant here, this would be a very different series, and I'd be writing a very different chapter.

Why the worry is reasonable

Schools have watched this pattern before. A piece of software gets a redesign, the screenshots look sharper, and six months later someone discovers that a workflow they relied on has quietly disappeared, or now takes four steps instead of one. Enough school MIS providers have done this that scepticism about school software modernisation is earned, not paranoid.

iSAMS built its reputation on depth. Query Builder alone has taught a generation of school administrators that iSAMS will let you ask almost any question of your own data. That's not a side benefit. For a lot of schools, particularly the ones with genuinely complex structures, that depth is the whole reason they chose iSAMS in the first place. Any change that puts it at risk deserves scrutiny, not blind trust.

So we want to be specific about what's actually changing.

Will iSAMS become less configurable?

No. Configurability is the part of iSAMS we're building around, not building away from. The work underway is about how that configurability is presented and reached, not about reducing what you can configure. A school running an unusual timetable structure, a bespoke reporting cycle, or a set of permissions built up over a decade of tweaks should still be able to do all of that once this work lands.

What should change is how much of that iSAMS already knows about your setup, and how directly it gets you there, rather than routing you through generic screens that don't reflect the configuration you've actually built.

Will existing functionality be removed?

Not as a side effect of a redesign, and not without the kind of consultation this series exists to describe. Any change to a workflow schools currently rely on goes through the same collaboration process I'll be writing about in more detail next chapter: product feedback, beta groups, and direct input from the schools actually using the feature day to day. If something genuinely needs to change, we'll say so, explain why, and give you time to prepare. What we won't do is quietly retire a capability because it made a demo look cleaner.

What will stay the same?

The complexity iSAMS can handle. The customisation options schools have built their processes around. The ability to get at your own data in the detail you need, not the detail a generic interface assumes is enough. Those aren't up for negotiation, and they're the reason “flexible school management system” has been a fair description of iSAMS for years. We intend for it to stay fair.

Surfacing depth, rather than removing it

Here's the distinction that matters most, and the one that's easiest to lose in a five-second scroll past a product announcement: making something easier to use is not the same as making it do less.

Think about a well-organised filing room versus a badly organised one. The well-organised version doesn't contain fewer files. It contains the same files, or often more, but you can find the one you need in thirty seconds instead of twenty minutes, because someone thought about how people actually search rather than just how things get stored. That's the job here. iSAMS' depth isn't disappearing. We're working on making it findable, understandable and usable by people who haven't spent a decade learning where everything lives.

That's a harder job than cutting a product back to its bare minimum and calling it progress. Simplifying is a one-way door: once a capability is gone, getting it back is a new project, and most vendors never bother. Surfacing existing depth without losing any of it means more careful, more collaborative, and considerably slower work. We think that trade-off is worth making.

What this means for you

If you're a power user who has spent years configuring iSAMS to fit a school that doesn't look like the brochure version of a school, this chapter is for you specifically. Nothing about how we're approaching school MIS configurability treats your setup as an edge case to be designed around. It's the reason this work exists.

If you're an IT lead or a school business manager weighing up the risk of change, the honest answer is that some things will look different over the coming months. Screens will move. Some paths to familiar functionality will get shorter. What won't move is the underlying capability you've built your operations around, and you'll have visibility into changes before they land, not after.

Next chapter, I'll go into more detail on how schools are actually shaping this work: the feedback we're gathering, the beta groups already running, and why customer input isn't a box we're ticking.

For now, the short version is the one that matters most: a more modern iSAMS is not a simpler one. It's the same depth, but built to be easier to reach.