Start here — what brought this migration onto your desk?

• Tell me briefly, what immediate trigger pushed your migration onto the agenda now?
• How long has your current student information system been in production and supported by your team? Options: Under 5 years, 5–10 years, 10–15 years, 15–25 years, More than 25 years
• Describe the hardest recent incident involving your current system and how it affected registration, financial aid, or student services operations for your staff and students.
• Which institutional deadlines or calendar constraints make the timing of this migration most sensitive for your team? Options: Start of term registration, Financial aid disbursement, Commencement, Budget cycle, Accreditation reporting, Other
• Who on your executive team will be judged most directly on the success of this migration? Options: CIO/CTO, Registrar, VP Enrollment/Provost, CFO, Other

If registration day goes sideways, what breaks first?

• If your SIS failed on the first day of registration, which three campus processes would stop first and why for your institution?
• Name the downstream systems in your campus ecosystem that would immediately surface errors or delays if those processes stopped. Options: Financial aid system, Billing and accounts receivable, Learning management system, CRM/admissions, Room scheduling, Reporting/data warehouse, Other
• Estimate the operational or financial impact to your student-facing cycles, such as registration throughput or aid disbursements, if those failures occurred during a peak cycle. Options: Minimal, Manageable with extra effort, Significant operational disruption, Severe financial or compliance exposure
• Who on your team becomes the crisis owner in that scenario and how quickly can they assemble cross-functional response resources?

Where time and money are leaking today

• What single ongoing cost or manual task in your registrar or records operations would make you walk away from this migration if it could not be reduced?
• List the top three manual reconciliation or workaround tasks your staff performs each semester that are driven by your current SIS limitations.
• How many full-time equivalent staff hours does that manual work consume in an average semester at your institution? Options: Under 40 hours, 40–160 hours, 160–400 hours, More than 400 hours
• When those manual steps fail, what compliance, reporting, or student-impact consequences have you experienced in the last two years?
• If your reconciliation workload were reduced by half, how would your department reallocate that capacity and what value would it create?

Decision makers, blockers, and governance

• Name the person with final signing authority and the stakeholder whose objection would stop the project in your governance model.
• List the campus offices that must formally endorse the migration before budget release, for example registrar, financial aid, or procurement.
• Describe the role faculty governance, shared governance committees, or unions play in your procurement and implementation timeline.
• Estimate the earliest realistic date your institution could have an executed contract if approvals proceed on your fastest internal timeline. Options: Within 30 days, 30–90 days, 90–180 days, More than 180 days
• Identify the single owner who will be accountable for benefits realization and adoption after go-live within your organization.

Other paths you are actively weighing

• Tell me frankly, which alternatives are you actively evaluating now including staying on your incumbent, upgrading internally, or a new commercial platform? Options: Stay on incumbent, Internal rebuild/upgrade, New commercial SIS, Hybrid approach, Other
• For each alternative you are considering, what would have to be true about cost, timeline, or risk for you to remain on that path instead of moving to a new platform?
• Has anyone on your team proposed solving the core issues with internal development, and if so what resourcing and timeline did they estimate? Options: Yes, with a published estimate, Yes, but no estimate, No internal proposal yet
• Rank these options by perceived overall risk at your institution, from highest risk to lowest: stay on incumbent, build internally, buy new SIS, hybrid. Options: Stay on incumbent, Build internally, Buy new SIS, Hybrid
• Which proof point, if demonstrated in a pilot, would make you rule out the incumbent and move to a new platform immediately?

Data and migration risks that can stop this deal

• Identify the single data, legal, or compliance risk in your environment that would stop the project immediately if it could not be mitigated.
• Which student record domains contain the most legacy complexity for your institution, for example transcripts, course history, or financial aid ledgers? Options: Transcripts and academic history, Course registration and schedule, Financial aid records, Billing and payments, Advising records, Other
• Do you have an authoritative data owner assigned for each of those domains and are they able to grant extract access when needed? Options: Yes, owners assigned and access available, Owners assigned but access limited, No owners assigned, Unknown
• Select the description that best matches the state of your historical student data extraction and documentation. Options: Well-documented and extractable, Partially documented, needs cleanup, Requires legacy exports with manual steps, Data trapped in unsupported systems
• Assuming we proved a migration approach that preserved 99.9% of critical student records, what remaining barrier would still keep you from proceeding?

Integration reality check — what must connect and who owns it

• Point to the single integration failure scenario that, if it occurred during migration, would create unacceptable operational risk for your campus.
• Provide the list of third-party systems that must be bi-directionally integrated for day-one operations at your institution. Options: Financial aid system, Billing/ERP, Learning management, Identity provider, CRM/admissions, State reporting system, Other
• For each required integration, choose the method your current system can support. Options: REST API with docs, SOAP API, Scheduled batch file export/import, Vendor-hosted connector, No programmatic access / screen-only
• Provide names and roles of the IT contacts who own each integration and indicate whether they have capacity to support development in the next quarter.
• Would you accept a phased cutover approach if a critical integration required vendor cooperation that cannot be obtained before go-live, or is that a showstopper for your institution? Options: Accept phased cutover, Showstopper, must have all integrations day one, Depends on which integration

Deployment windows, rollback plans, and approvals

• Point to the deployment constraint in your environment, such as a hard registration window, compliance review, or union agreement, that will force your go-live date.
• Select which of these must be completed before your team will approve a cutover window. Options: Historical data extracts validated, Integration smoke tests passed, Registrar sign-off on processes, Financial aid parallel processing verified, Executive sponsor approval
• Do you have a documented rollback plan and has your team executed a restore drill for critical student data in the past 18 months? Options: Yes, documented and tested, Documented but not recently tested, No rollback plan, Unknown
• A typical year, how many weekend or holiday windows are available for risky cutover work at your institution? Options: 0, 1–2, 3–4, More than 4
• Can your operational and IT teams commit to a deployment plan that requires three full weekends of focused cutover work, or would that commitment block the project? Options: We can commit, We cannot commit, Maybe with vendor-led resources

How will you know this project is successful?

• State the single measurable signal your executive sponsor will accept to close the project as successful.
• Detail the acceptance criteria that define accuracy and timeliness for registration and financial aid processing in your environment.
• Choose the monitoring signals that are most important to track in the first 90 days post-go-live. Options: Data reconciliation within tolerance, Registration throughput meets baseline, Financial aid disbursal timelines met, API error rate below threshold, User adoption and task completion rates
• When adoption metrics lag 20 percent in the first semester, who in your governance will decide remediation and what authority will they have to change scope or funding?
• State the intended cadence for executive steering during implementation and which roles must attend to approve scope changes. Options: Weekly, Biweekly, Monthly, Ad hoc as needed

Decision triggers and immediate next steps

• Assuming the pilot demonstrates the expected outcomes, what remaining approvals or blockers would still prevent you from signing within one week?
• Choose the pilot scope you prefer to validate migration approach and integrations. Options: Subset historical records migrated with full integrations, Integration-only smoke test with live records, Full functional pilot on a small student population, Sandbox validation with production extracts
• Supply names and roles for the people who must attend the pilot review and indicate who will issue the go or no-go decision.
• What is the single most important deliverable your team needs from us before the pilot begins?
• Propose three dates within the next four weeks when your integration owners are available for a 90-minute technical scoping session.

• Solution Experience: Records, Registration, and Migration Walkthrough

• Confirm the current state and its cost
• You confirm the demonstrated workflows eliminate the manual rework you described during Discovery.
• Deliver a tailored migration pilot plan that specifies sample size, validation checks, success metrics, and timeline.
• You agree that the migration approach preserves the integrity of historical records at an acceptable accuracy threshold.
• Walk through the degree audit and registration workflow using your scenario
• Provide an anonymized extract of the busiest registration scenario and representative historic records for the migration pilot.
• Provide integration endpoint details and primary contacts for financial aid and billing systems.
• You accept the integration approach shown will maintain financial aid and billing continuity during cutover and parallel operation.
• Show migration sample results for historical records
• Validate integration continuity for financial aid and billing
• You agree on the specific evidence and pilot scope required before a final decision.
• Schedule dates for the migration pilot and integration continuity tests.
• Forced validation, confirm this maps to your needs
• Agree remaining evidence and next steps

• Solution Experience: Records, Registration, and Migration Walkthrough
• Solution Experience Deck
• Solution Brief

• meeting
• slides
• document

• Configure Core Student Records and Academic Structure
• Migrate Historical Student Academic Records
• Migrate Financial Aid and Billing Records
• Configure Registration and Course Scheduling
• Implement Degree Audit and Graduation Rules
• Integrate with Campus Identity and Directory Services
• Integrate with Learning Management Systems (LMS)
• Build Financial Aid and Billing Integrations
• Configure Self-Service Student and Advisor Portals
• Deploy Mobile Access and Responsive UI
• Configure Enrollment Reporting and Compliance Exports
• Train Registrar and Administrative Staff
• Provide Parallel Operations and Cutover Support
• Perform Data Reconciliation and Quality Assurance

Configure Core Student Records and Academic Structure

• Which core student record entities must be modeled in the new system (for example: transcript history, course registrations, program declarations, academic standing records)?
• How many academic calendars or term models do you operate (for example: semester, quarter, modular sessions, continuous intake)? Options: 1 calendar, 2 calendars, 3 or more calendars
• List the legacy identifier types that must be preserved for auditability (for example: legacy student ID, old registration number, external vendor reference).
• Who in your office will own canonical course catalog updates and program code maintenance during implementation?
• Specify any custom academic attributes or local code tables that must be included (for example: cohort tags, curriculum pathways, special admission codes).
• Are there regulatory constraints on storing historical records (for example: state retention rules or FERPA release flags) that affect schema design? Options: Yes, No

Migrate Historical Student Academic Records

• Which transcript artifacts must be migrated from your current platform (for example: term-level grades, grade-change logs, transfer credit evaluations, unofficial transcripts)?
• How many total academic record rows or student transcript records are in scope (estimate by rows or years of records)? Options: Less than 100k rows, 100k-1M rows, More than 1M rows
• Describe the source formats for historical records we will extract from (for example: fixed-width exports, relational exports, PDF transcripts, XML grade feeds).
• Identify any archival media or offline sources that require special handling (for example: tape archives, departmental spreadsheets, scanned transcripts).
• What acceptance criteria will confirm migrated academic transcripts meet your completeness and accuracy needs (for example: percentage field-level match, reconciliation counts by term, verified sample transcripts)? Options: >= 99.5% field-level accuracy, >= 99.0% field-level accuracy, Custom threshold and verification plan
• When do you require finalized schema mapping sign-off for transcripts to start full-scale migration? Options: Before pilot migration, After pilot data pass, As part of migration runbook approval

Migrate Financial Aid and Billing Records

• Which financial aid artifacts are in scope for migration (for example: award packages, disbursement history, Title IV batch records, SAP evaluations)?
• How many billing ledger entries or invoice rows must be migrated (estimate by fiscal years or transaction counts)? Options: Less than 50k, 50k-500k, More than 500k
• Describe the file formats or export feeds for financial aid and billing data (for example: NACHA files, EDI-like extracts, CSV ledgers, GL journal exports).
• Which downstream systems must receive continued financial aid and billing integrations during cutover (for example: state disbursement portal, payment gateway, student billing portal)?
• What reconciliation tolerance will you accept for migrated billing balances and financial aid awards at go-live (for example: dollar threshold per student or percentage of accounts reconciled)? Options: Per-student tolerance ($), Overall balance variance (%), Exact match required for specified cohorts
• Identify who will authorize hold/release rules on student accounts during the migration of billing and aid records.

Configure Registration and Course Scheduling

• Which registration rules drive your busiest cycle (for example: enrollment caps, reserve seats, cross-listed sections, corequisite checks)?
• How many concurrent registration transactions per minute should the system support during peak enrollment windows? Options: <100 tpm, 100-500 tpm, 500+ tpm
• Specify your waitlist and override policies that must be enforced (for example: time-limited holds, advisor overrides, automated enroll-from-waitlist).
• Who currently manages CRN lifecycle and who will approve master schedule changes during implementation?
• Identify any complex scheduling constraints the platform must support (for example: room rotation patterns, time-band conflicts, linked lab sections).
• Are there external registration feeds to maintain during cutover (for example: third-party registration portals, dual-enrollment partners)? Options: Yes, No

Implement Degree Audit and Graduation Rules

• Which degree programs and catalogs must be modeled first for graduation audit (list top 5 priority programs by enrollment)?
• Describe the catalog year and rule exceptions policy that governs degree requirements for continuing students.
• Identify known degree audit edge cases that require manual routing (for example: interdisciplinary transfers, competency-based credits, dual-degree pathways).
• Specify how you validate graduation decisions today (for example: sample audit reports, graduation committee sign-offs, automated certification), and which method we should mirror for testing.
• Who will provide official curriculum documents and program maps for rule configuration and unit testing?
• How many representative student degree plans should be used as test cases to validate the degree audit engine? Options: 10-50, 51-200, 200+

Integrate with Campus Identity and Directory Services

• Which identity stores must be integrated for single sign-on and account provisioning (for example: LDAP/Active Directory, SAML identity provider, OIDC)?
• Describe the attribute mapping required for accounts (for example: affiliation, student type, proxy authorizations, advisor relationships).
• Identify any multi-factor authentication or conditional access policies that must be preserved during migration.
• Who will approve service account credentials and where will secrets be stored for production integrations?
• Specify whether scoped provisioning (create/update/delete) is required for automated account lifecycle versus manual provisioning only. Options: Automated create/update/delete, Automated update only, Manual provisioning
• Are there scheduled directory-sync windows we must avoid to prevent race conditions with other campus systems? Options: Yes, No

Integrate with Learning Management Systems (LMS)

• Which LMS integration surfaces do you require (for example: enrollment roster sync, gradebook passback, assignment links)?
• How many course sections per term must be synchronized to the LMS at peak (estimate average/peak counts)? Options: <1k sections, 1k-5k sections, 5k+ sections
• Describe your grade exchange requirements and acceptable mapping rules for grade scales and incomplete grades.
• Identify any LMS-specific roster rules (for example: student observers, cross-institution enrollments, external instructor accounts).
• Who will be the LMS administrator contact for API credentials and testing access?
• Are there synchronous classroom scheduling rules that must be honored when creating LMS sections (for example: lab cohorts, multi-campus sections)? Options: Yes, No

Build Financial Aid and Billing Integrations

• Which external payment and refund endpoints must be connected (for example: payment gateway, ACH processor, third-party payment portal)?
• Describe the nightly or batch file exchanges required for award origination and disbursement processing (for example: file frequency, expected record counts).
• Identify any treasury or bank-specific file formats or encryption requirements that we must support for funds transfers.
• Who will certify testing for end-to-end billing flows (for example: bursar, controller, payment operations)?
• Specify rules for account holds and release triggers tied to financial aid disbursement events.
• Are refunds and reconciliations subject to an external audit window that dictates cutover timing (for example: month-end close, quarter-end)? Options: Yes, No

Configure Self-Service Student and Advisor Portals

• Which portal features are required at go-live (for example: enrollment, unofficial transcript download, degree audit view, account billing)?
• Describe advisor roles and the specific views or actions advisors must have (for example: advisee rosters, permission to override holds, note-taking).
• Identify any paper workflows you want converted to self-service forms (for example: program change requests, graduation petitions).
• Who will be responsible for approving content and templates that appear in student-facing pages?
• Are there accessibility (for example: Section 508) or multilingual requirements for portal content at launch? Options: Accessibility required, Multilingual required, Both, Neither
• Do you require offline or low-bandwidth modes for the student mobile portal during peak registration? Options: Yes, No

Deploy Mobile Access and Responsive UI

• Which user journeys must be mobile-optimized before go-live (for example: add/drop registration, grade lookup, billing payment)?
• Select the minimum device and browser support baseline you expect at launch. Options: Modern mobile browsers only, iOS and Android apps plus responsive web, Broader backward-compatible support
• Specify any device-specific capabilities required (for example: push notifications for registration alerts, camera upload for ID verification).
• Who will own accessibility testing and sign-off for mobile interfaces?
• Indicate performance targets you expect for mobile flows during peak hours (for example: page load under 3 seconds, API response under 500ms).
• Are there branding or theming constraints that must be present in the mobile UI at go-live? Options: Institutional brand required, Co-branding allowed, Flexible theming

• desired_state
• current_state
• gaps
• success_criteria
• decision_readiness
• stakeholders
• desired_state
• decision_readiness
• current_state
• success_criteria
• gaps
• stakeholders
• success_criteria
• desired_state
• decision_readiness
• stakeholders
• gaps
• current_state
• current_state
• desired_state
• decision_readiness
• gaps
• success_criteria
• decision_readiness
• decision_readiness
• decision_readiness

• Master Services Agreement (MSA)
• Statement of Work (SOW)
• Subscription Order Form
• Service Level Agreement (SLA)
• FERPA Data Processing Addendum (DPA)
• Migration Acceptance & Go/No-Go Criteria
• Resource & Timeline Commitment
• Change Order Agreement
• Payment Schedule Agreement
• Intellectual Property & Confidentiality Schedule

• Go-live Health Check
• First Measurement Review (Weeks 4-10)
• 90-day Outcomes Review and Incumbent Wind-down
• Operational Quarterly Review
• Annual Success Review and Lessons Learned

• Schedule targeted role-based training sessions for areas with low proficiency rates.
• If decommissioned, create and circulate the legacy system archival record and confirm read-only access removal steps.
• Publish a remediation tracker for any unmet Solution Scope targets with resolution owners and dates.
• Configure recurring metric reports for registration success rate and financial aid accuracy for quarterly review meetings.
• Adoption trend review and training needs
• Confirm adoption is progressing toward Solution Scope targets or identify targeted interventions.
• Reduce critical incident backlog and lower mean time to resolve for recurring production issues.
• Produce a prioritized list of enhancements to be actioned or deferred next quarter.
• Re-confirm success criteria and owners
• Close or escalate all priority incidents older than the agreed SLA and document resolutions.
• Publish the prioritized enhancement backlog and define the intake process for new requests.
• Present 12-month outcomes vs Solution Scope targets
• Confirm whether adoption retention rate and data migration completeness meet the Solution Scope targets after 12 months.
• Capture and document at least five concrete lessons learned and suggested process improvements.
• Establish a maintained shared channel for issues and enhancement requests and agree expected response SLAs.
• Publish the annual outcomes report comparing measured metrics to Solution Scope targets and distribute to stakeholders.
• Publish the lessons learned document and recommended process changes for future projects.
• Create and maintain the shared enhancement intake channel with an initial triage workflow and response SLA.
• Confirm the deployment completed and list the top 5 production issues with expected resolution dates.
• Verify integrations required for registration and financial aid are reachable and processing jobs have run without fatal errors since cutover.
• Agree immediate remediation steps and where to escalate if deadlines slip.
• Publish a one-page go-live health summary including migration job status, open critical issues, and temporary workarounds.
• Open or update priority-1 tickets for each critical blocker with target resolution dates.
• Schedule the First Measurement Review within 4-10 weeks to evaluate early KPI trends.
• Present first measurement data vs Solution Scope targets
• Determine whether weekly active users in student records workflows and data migration completeness are trending toward Solution Scope targets.
• Produce a root-cause list for each off-target metric with discrete corrective actions and deadlines.
• Confirm the target date for the next outcomes review that will validate readiness for steady-state operations.
• Publish the first-measurement dashboard and remediation plan with metric baselines and expected improvement milestones.
• Execute agreed migration or data-correction scripts and document results for the next review.
• Provide a timeline for required training activities to increase weekly active user counts.
• Restate acceptance targets from Solution Scope
• Determine which Solution Scope targets for registration processing and financial aid accuracy are met and which require remediation.
• Confirm the incumbent system decommission decision and the plan for archival or read-only retention, including contract resolution status.
• Agree final remediation tasks, completion dates, and the ongoing monitoring cadence.
• Incident and hypercare ticket burn-down
• Capture lessons learned
• Present outcome data for the 90-day window
• Diagnose root causes for any gaps
• Deployment and migration validation
• Enhancement backlog review
• Incumbent system wind-down checkpoint
• Enhancement intake and shared channel setup
• Agree corrective actions and owners
• Early adoption signals and usage patterns
• Agree long-term monitoring cadence
• Blockers and open issues
• Confirm timeline to acceptance gate
• Operational risks and next quarter plan
• Document remediation for unmet criteria
• Agree immediate remediation actions
• Agree monitoring and reporting cadence going forward