Most districts allow 4 to 9 months from decision to full cutover when leaving a legacy platform. The largest single variable is data migration complexity. Districts with clean, well-documented data can move faster. Districts with 20 years of accumulated customizations and inconsistent data need more time.

After you've signed with a replacement vendor and started implementation planning, not before. Legacy vendors often become less responsive once they know a customer is leaving, and you'll need vendor support for the final data export. Give notice as required by your contract, typically 30 to 90 days before the contract expires.

Request in writing, referencing your contract's data ownership and portability terms. Specify the formats you need (typically CSV or SQL exports). Include historical data for all years you want to retain. Ask for data dictionaries or schema documentation so your new vendor can map fields correctly. Allow at least 60 days for the vendor to fulfill a comprehensive export request.

At minimum: current-year student demographics, enrollment, attendance, gradebook data, transcripts, special education records, contact information, and state reporting fields. Consider bringing historical academic records (transcripts should typically go back at least 5 years). Some districts also bring behavioral incident records and health records. Not everything needs to migrate - archive what you don't need in the new system.

Summer, between school years, is by far the most common. This avoids disrupting attendance, gradebook data, and state reporting mid-cycle. Some districts do winter break cutovers for semester-based schools. Mid-year switches during a school year are possible but require significantly more planning and risk mitigation.

Confirm with your state whether they need to be notified of the SIS change (some states do, some don't). Ensure the new vendor can handle your state's reporting requirements before you go live. Plan the switch timing to avoid overlap with major state submission deadlines. Keep the old system accessible for at least one reporting cycle after cutover in case reconciliation is needed.

Resistance is normal and manageable. It typically stems from three sources: fear of the learning curve, attachment to workflows they've built over years, and skepticism about whether the new platform will actually be better. Address each directly: over-invest in training, involve resistant staff in workflow design decisions, and provide clear timelines for when they'll be productive on the new platform. Most staff who are anxious in month 1 are advocates by month 6.

Yes, and it's often recommended for 2 to 4 weeks around cutover. Parallel operation lets you validate that data has migrated correctly, gives staff a fallback if the new system has issues, and creates a smooth transition rather than a hard cutoff. Longer parallel runs (more than 4 weeks) typically create confusion and are not recommended.