Move off a legacy SIS or ERP in weeks
We model your institution once, then project it onto the new platform, one area at a time.
Built for the CIO, the registrar, and the controller
The problem
Why migrations take years
The time goes to learning the institution, rebuilding mappings, and absorbing all the risk at one cutover.
Consultants start by learning your business
Months of interviews and workshops before anything moves.
Mappings live in spreadsheets
Errors surface at test loads, and every fix starts another cycle.
The new system dictates the process
Gaps turn into customizations, workarounds, or lost features.
Everything moves at once
One cutover weekend carries all of the risk.
Represent
Your institution, modeled once from the systems you run today
Legacy systems, spreadsheets, policies, and past decisions become one ontology of the institution: its objects, relationships, logic, and actions.
A slice of the full model: the labeled objects are the ones this work runs on most.
Program
A degree program and the courses it requires, as the catalog defines it.
- degree
- enum
- catalog_year
- integer
- is pursued byStudentmany
- requiresCoursemany
Course
A catalog course with its subject, number, credits, and prerequisites.
- subject
- string
- number
- string
- credits
- decimal
- is required byProgrammany
- offered asSectionmany
Section
One offering of a course, with its capacity and how it meets.
- capacity
- integer
- modality
- enum
- offersCourseone
- enrollsStudentmany
Hold
A block on registration or transcripts, wherever the legacy systems recorded it.
- kind
- enum
- blocks_registration
- boolean
- placed onStudentone
- is triggered byAccountone
Student
One student career, with its standing and residency converted to the institution's own codes.
- student_id
- string
- credits_earned
- decimal
- entry_term
- term
- ƒresidency
convert(legacy_code, residency_map)- ƒclass_standing
standing(credits_earned, program.rules)
- is the person behindPersonone
- pursuesProgramone
- takesSectionmany
- carriesHoldmany
- is billed throughAccountone
Person
One person, resolved across every legacy record that describes them as a student, an employee, or both.
- legal_name
- string
- birth_date
- date
- legacy_ids
- list
- same_person
- Chance two legacy records describe the same person. From student, employee, and the names, birth dates, addresses, and IDs on every legacy record.
- ƒprimary_address
standardize( latest(addresses where verified), postal reference)
- enrolls asStudentmany
- works asEmployeemany
Employee
A person employed by the institution, from the HR and payroll records.
- employee_id
- string
- hire_date
- date
- is the person behindPersonone
- fillsPositionone
Position
A budgeted role in a department, filled or vacant.
- title
- string
- fte
- decimal
- is filled byEmployeeone
- sits inDepartmentone
Aid award
Aid offered to a student for a term.
- amount
- money
- status
- enum
- pays intoAccountone
Account
The student's account: every charge, payment, and disbursement the legacy systems hold.
- charges
- money
- payments
- money
- ƒbalance_due
charges − payments − disbursed aid
- billsStudentone
- is paid byAid awardmany
- triggersHoldmany
Department
A unit with a budget, positions, and purchases.
- cost_center
- string
- budget_owner
- string
- includesPositionmany
- buys fromVendormany
Vendor
A company the institution buys from, often entered more than once over the years.
- legal_name
- string
- tax_status
- enum
- duplicate_of
- Flags a vendor entered again under a different name or address. From department.
- sells toDepartmentmany
Project
Projected onto the new platform, property by property
Every field on the new platform comes from the model through a rule on file. Areas go live one at a time, every record is read back, and anything the platform lacks becomes a custom app.
What changes
Faster, and on your terms
Live in weeks
You map once, at the model. Every load, check, and reconciliation runs from it.
Your business, designed your way
Decide how you want to operate in the model, then configure the new platform to match.
No months of consultants learning your business
The model already holds your data, rules, and exceptions, read from your systems and documents.
Incremental go-live
The model reconciles both systems continuously, so areas can move one at a time.
Custom apps for any gap
If the new platform lacks something you need, we launch an app on the same model.
How it runs
Six steps, with every record verified
- 1Represent your institutionEvery system, spreadsheet, policy, and past decision is read into one model, with data quality profiled up front.
- 2Design how you want to runProcesses, codes, and structures are decided in the model, each with an owner, before anything is configured.
- 3Project to the new platformThe new platform's configuration and data are generated from the model, not rebuilt by hand.
- 4Load and verify in phasesRecords load through the platform's APIs, canary records first, and every one is read back against the model.
- 5Go live in incrementsOne area moves at a time while the model keeps the old and new systems reconciled.
- 6Fill gaps with custom appsAnything the new platform lacks becomes an app on the same model.
Plan your migration on the model
We scope the first area with your team and agree on how to measure it.
