Solutions · By need · SIS modernisation

Move off the legacy student record without freezing the institution.

Nobody replaces a student information system because they want to. They do it because every change is a change request, the regulator wants evidence the system cannot produce, and the people who understood the customisations have retired. Modernisation does not have to mean a year-long freeze and a single terrifying weekend. It can be one function at a time, in parallel, with the history brought across.

Talk through your migration See how it is done

Why now

A legacy SIS rarely fails. It just stops being able to change.

The system still runs. Students still register, results still publish. What has gone is the ability to respond: a new pathway takes two releases, a regulator asks for evidence in a shape the database cannot produce, and the one person who knew why a field was repurposed in 2011 has left.

That is the real cost of a legacy record. Not downtime, but a slow narrowing of what the institution is able to decide, because the software can no longer follow.

The problem: a system that outlives the policy it encodes.
Six signals it is time One of these is normal. Four of them is a decision you have already made.
  • Policy changes need a release A new rule becomes a change request
    The academic calendar waits on a development queue
  • You cannot take the upgrade A customisation blocks the version
    Security and support fall behind to protect a workaround
  • Knowledge has left the building Undocumented fields, remembered by nobody
    Changes are avoided rather than risked
  • Evidence has to be rebuilt Extracts and spreadsheets before every review
    Audit season consumes the people you can least spare
  • Every new tool needs an interface Another nightly file, another owner
    The estate grows faster than the team maintaining it
  • Students expect self-service Requests handled by email and counter queues
    Staff absorb work the system should be doing

Six signals, one conclusion: the constraint is the record model, and no amount of reporting on top of it will move.

The difference

Three routes, and only one changes the operating model.

Modernisation gets used to mean three very different things. It is worth being precise, because the cost, the risk and what you own at the end are not the same.

Route one

Stay and patch

Keep the legacy record, add tools around it.

What changesEach new need gets its own tool and its own interface.
PolicyStays split across systems and custom code.
EvidenceRebuilt from extracts before each review.
RiskLow today, compounding every year.
At the endA larger estate and the same constraint.
Route two

Re-platform to a newer SIS

Same operating model, newer software.

What changesThe vendor, the interface and the contract.
PolicyStill written into each system separately.
EvidenceStill assembled, from a newer database.
RiskConcentrated into one cutover event.
At the endA modern SIS, and the coordination work still with your team.
Route three

Modernise onto one governed record

Change what owns the record, not just what runs it.

What changesEvery lifecycle reads and writes one governed record.
PolicyConfigured once, applied wherever the decision is made.
EvidenceA by-product of the work, tagged as it happens.
RiskSpread across phases, each one reversible.
At the endOne record you own, and a smaller estate around it.
Re-platforming answers “what do we run it on”. Modernising answers “who owns the record”.

How it is done

Six phases, and the legacy system stays live through five of them.

Each phase leaves something usable behind, and each one can be stopped without stranding the institution. Nothing is switched off until the function that replaced it has run a real cycle.

Legacy live Creatrix owns it Both, compared Retired
  1. 01

    Assess what you actually have

    The current record model, the customisations nobody documented, the interfaces that depend on them, and which of those still earn their place.

    Record model · Customisations
  2. 02

    Scope one function, not the estate

    Pick the one that is failing loudest and make Creatrix the system of record for it. Everything else keeps running exactly as it does today.

    Scope · Ownership
  3. 03

    Bring structures and history across

    Programmes, courses, people, results and awards arrive by bulk import into the model you will keep, so past transcripts are served from one place rather than an archive.

    Import · History
  4. 04

    Configure the policy instead of coding it

    Calendars, grading schemes, eligibility rules, approval chains and roles become visible settings, which is how the regulations buried in custom code come back into the light.

    Rules · Roles
  5. 05

    Run one real cycle in parallel

    A term, an intake or a review goes through end to end while the legacy system is still live, and the outputs are compared before anything is trusted.

    Parallel · Comparison
  6. 06

    Cut over, then decommission

    Move the function across, retire the interfaces it needed, and start the next one on a core that is already configured. The legacy system goes last.

    Cutover · Retire

What usually goes wrong

The failure modes are well known. Design them out.

Student record projects rarely fail on technology. They fail on scope, on data nobody owned, and on a cutover with no way back. These are the six worth planning against.

Everything moves at once
InsteadOne function owns the record first, and the rest of the estate keeps running until its turn.
The old customisations get rebuilt
InsteadAsk what policy each one was enforcing, then configure the policy. Most were workarounds for a system that could not be told the rule.
History is left behind in an archive
InsteadMigrate student, result and award history into the same record model, so a transcript request twenty years old is answered from the live system.
Cutover with no way back
InsteadRun one real cycle in parallel and compare outputs. If it does not hold, nothing has been switched off.
Training treated as a launch event
InsteadThe offices that own the function work in it through the parallel cycle, so go-live is the day they stop using the old one.
Nobody switches the old system off
InsteadEvery phase names what it retires. A modernisation that only adds systems has not modernised anything.

What you land on

The destination is an operating model, not a database.

Worth reading before you write the business case: what the layer is, why the old architecture ran out of road, and how a change actually travels once it is in place.

The case Why SIS and ERP fall short Every application works and the institution still fragments. The argument your business case needs. Read the argument → The category What is an Academic OS The layer that governs SIS, LMS and ERP rather than competing with them. Read the definition → Mechanics How it works How a change approved in one place is understood everywhere else, without an interface. See how it works → The map Lifecycle architecture The lifecycles and the one core they run on, so you can see the end state before phase one. See the architecture → For IT The CIO view Identity, policy, workflow, integration and audit: the layers your team stops building by hand. See the CIO page → Commercials How we price What a first phase commits you to, and how scope expands without a second negotiation. See pricing →

Where phase one usually starts

Pick the function that is failing loudest.

Each of these can be the system of record for its function while the legacy SIS still runs, with bulk import for the history and documented APIs for what stays behind.

The record
Student Information System →

Student records, registration, progression, transcripts and verification, with history migrated into the same model.

RecordsRegistrationTranscripts
 The front door
Admissions CRM →

Often phase one, because it is self-contained and the enrolled student can be handed to the legacy SIS until it is retired.

PipelineOffersEnrollment
 The term
Class Scheduling →

Timetables validated against rooms, availability and clashes, which is usually where the legacy system hurts most visibly.

TimetablesValidationPublication
 Results
Examination Management →

Eligibility, seating, evaluation, tabulation and results on one exam record, feeding transcripts that can be trusted.

EligibilityResultsRevaluation
 The structure
Curriculum & Catalog →

Versioned curriculum and the published catalog, the structure every other phase schedules and confers against.

VersionsCatalogCredits
 Evidence
Accreditation & Evidence →

Sometimes the trigger for the whole programme: a review the legacy record could not evidence.

EvidenceStandardsCoverage
Start with one. The core underneath is the same for the next.

Universities across Europe, the Middle East, Southeast Asia and Oceania run their academic record on Creatrix.

It’s convenient to have all academic and administrative activities managed in one system. It helps keep work organized and reduces manual effort.
Arit · Assistant Registrar, IT Higher education institution · via G2
Creatrix provides an excellent platform for timetabling, enabling teaching activities to be planned and coordinated through a clear line of sight to learning outcomes, assessments, professional competency standards and graduate attributes.
Andy C. · Faculty Manager School of Pharmacy · via G2

Frequently asked

The questions that decide the business case.

What is SIS modernisation?

SIS modernisation is moving the student record off a legacy system onto a governed, configurable platform, so academic policy, workflow and reporting live in the system rather than in customisations, spreadsheets and the memory of long-serving staff.

The distinction that matters: it is a change of operating model, not only a change of vendor.

How is this different from re-platforming to a newer SIS?

Re-platforming moves the same operating model onto newer software. The record is still one system's property, policy is still written into each system separately, and the coordination work between systems stays with your team.

Modernising onto an Academic OS puts every lifecycle on one governed core, so a record is owned once and read by all of them. That is the difference between a newer database and a different architecture.

Do we have to switch everything off at once?

No, and we would advise against it. Creatrix can be the system of record for one function while the legacy SIS keeps running, connected through documented APIs and bulk import.

Institutions cut over function by function and decommission as they go, so the risk is spread across phases rather than concentrated into one weekend.

What happens to twenty years of historical records?

Historical student, result and award data is migrated into the same record model, so past transcripts and verification requests are served from one place rather than from an archive nobody maintains.

Version history is retained on academic policy objects, so a transcript issued under an older grading scheme can still be explained years later.

Our regulations are buried in custom code. Does that have to be rebuilt?

Usually not as code. Academic calendars, grading schemes, eligibility and promotion rules, approval chains, holds and restrictions are configuration, set per programme, intake and campus.

The useful question during assessment is not “how do we rebuild this customisation” but “what policy was it enforcing”. Most legacy customisations exist because the system could not be told the rule.

How do we know the new system is right before we trust it?

By running one real cycle in parallel: a term, an intake or a programme review goes through end to end while the legacy system is still live, and the outputs are compared.

The test is not a demo. It is whether the office that owns the function stopped keeping its private spreadsheet.

GET STARTED

Bring your current record model. We will map the first phase against it.

Tell us what the legacy system holds, what has been customised, and which function hurts most. The useful conversation is about phase one, not the end state.

Talk through your migration Talk to us