Complete School Data Migration Guide

Step 1.1: Export Complete Data Inventory

Begin by generating a comprehensive inventory of all data in your source system. This is not a simple record count — you need structural understanding.

• Generate schema documentation showing all tables, fields, and relationships
• Export record counts for every table (students, staff, courses, enrollments, grades, attendance, behavior, documents)
• Identify custom fields, local code tables, and non-standard modifications
• Document data types, field lengths, and validation rules
• Map relationships between tables (foreign keys, dependent records)

Step 1.2: Data Quality Assessment

Clean data is easier to migrate than dirty data. Run automated profiling to identify:

• Duplicate records: Students enrolled twice, staff with multiple IDs, duplicate course sections
• Orphaned records: Grade entries without matching students, attendance logs for withdrawn pupils
• Missing required fields: Blank birthdates, missing guardian contacts, incomplete addresses
• Invalid data: Future dates in historical fields, negative attendance counts, impossible GPAs
• Inconsistent formatting: Phone numbers in mixed formats, addresses without standardization

Step 1.3: Custom Field Documentation

Every school modifies their SIS to some degree. Document:

• Custom fields added to student, staff, or course records
• Local code tables (behavior codes, attendance reasons, grade scales)
• Report card templates and calculation formulas
• Workflow automations and notification rules
• Third-party integrations and their data dependencies

Determine whether each custom element maps directly to the new system, requires transformation, or must be rebuilt manually.

Step 1.4: Compliance & Legal Review

Before moving any data, verify your legal obligations:

• FERPA (U.S.): Ensure both vendors have signed Data Processing Agreements. Verify the new vendor qualifies as a "school official" under 34 CFR § 99.31(a)(1).
• GDPR (EU/UK): Document lawful basis for processing (Article 6). If transferring outside the EEA, implement Standard Contractual Clauses (Articles 44–49).
• State laws: Check your state's specific student data privacy laws (e.g., California's SOPIPA, New York's Education Law § 2-d).
• Retention requirements: Confirm how long you must retain different record types. Do not delete anything before confirming retention obligations.

Step 1.5: Create Data Mapping Document

The data mapping document is your migration blueprint. For every field that will be transferred, specify:

Step 1.6: Backup & Rollback Plan

Before any transfer begins:

• Take a full database dump in a vendor-neutral format (SQL, CSV, XML)
• Copy all attached files, photos, and documents to secure offline storage
• Verify backup integrity by restoring to a test environment
• Document the rollback procedure: who decides, how long it takes, what data is lost
• Define failure thresholds: at what error rate do you abort and restore?

Step 2.1: Test Migration (5% Sample)

Never run a full production transfer without testing first. Select a representative 5% sample that includes:

• Current students across all grade levels
• Recently graduated students (for transcript verification)
• Staff from multiple departments
• Records with custom fields and non-standard data
• International students (to test character encoding)

Run the test migration using your finalized data mapping document. Then validate:

• Record counts match between source and destination
• Character encoding is correct (no garbled names or addresses)
• Date formats are consistent (MM/DD/YYYY vs DD/MM/YYYY)
• Calculated fields (GPA, credits) produce expected results
• Relationships are preserved (students linked to correct courses and grades)

Step 2.2: Fix Issues & Refine Mapping

Based on test results, update your data mapping document:

• Correct transformation rules that produced errors
• Adjust field mappings for data that didn't transfer correctly
• Add handling for edge cases discovered in the sample
• Document any data that cannot be mapped and requires manual entry

Run a second test migration if significant changes were made. Do not proceed to full transfer until the test migration passes all validation checks.

Step 2.3: Prepare the Environment

Before the full transfer:

• Notify all stakeholders of the migration window (at least 2 weeks notice)
• Lock write access to the source system during final sync
• Ensure the destination system is configured and ready to receive data
• Verify network capacity for large data transfers
• Have technical support contacts available from both vendors
• Prepare a communication plan for status updates during the migration

Step 2.4: Execute Full Transfer

Execute the transfer in sequential batches:

1. Reference data first: Schools, campuses, departments, grading scales, code tables
2. Identity records second: Students, staff, guardians (the "who")
3. Relationship records third: Enrollments, course assignments, scheduling (the "what")
4. Historical data fourth: Grades, attendance, behavior records (the "history")
5. Documents and files last: Photos, IEPs, scanned documents, report cards

After each batch, verify record counts before proceeding to the next. This staged approach makes it easier to identify where errors originate.

Step 2.5: Monitor & Log

Throughout the transfer:

• Maintain detailed logs of every operation, including timestamps and operator names
• Monitor for error messages, warnings, or unexpected behavior
• Track transfer speed to estimate completion time
• Document any deviations from the planned procedure
• Take periodic snapshots of the destination system for rollback points

Step 3.1: Record Count Verification

Compare totals across all major tables:

Step 3.2: Spot-Check Sampling

Manually verify 10–20 random records end-to-end:

• Pull a random student record from the source system
• Locate the same student in the destination system
• Compare every field: name, birthdate, address, guardian contacts, enrollment dates
• Verify grade history, attendance summary, and behavior records
• Check that documents (photos, IEPs) are attached and viewable

Document any discrepancies and determine whether they are isolated errors or systemic issues.

Step 3.3: Calculated Field Verification

Verify that automated calculations match between systems:

• GPA calculations (weighted and unweighted)
• Credit totals and completion percentages
• Attendance rates and tardy counts
• Behavior incident frequencies
• Custom report card calculations

Calculation methods may differ between platforms. Document any differences and obtain stakeholder sign-off on the new calculation methodology.

Step 3.4: User Access Testing

Verify that all user types can access the system:

• Administrators: Full system access, user management, reporting
• Teachers: Gradebook access, attendance entry, parent communication
• Students: Portal login, grade viewing, schedule access
• Parents: Portal login, student data viewing, communication tools
• Counselors: Student records, scheduling tools, transcript generation

Test password resets, email notifications, and mobile app access if applicable.

Step 3.5: Report Comparison

Run identical reports in both systems and compare outputs:

• Enrollment summary by grade level
• Honor roll / failing students list
• Attendance summary by homeroom
• State reporting extracts
• Transcript samples

Step 3.6: Parallel Operation Period

Keep the old system in read-only mode for 30 days after go-live. This safety net allows staff to:

• Verify data accuracy while learning the new system
• Retrieve any records that may have been missed
• Compare reports if discrepancies are reported
• Maintain confidence during the transition period