One of the most challenging parts of building an integration is migrating existing schools. Years of accumulated (and sometimes fragmented) data can make it difficult to ensure that all of the data is migrated correctly. This guide will help you understand the best practices for migrating existing schools to your integration.
Please note, this guide is intended for to help you preserve existing customer data when migrating to Edlink. If you are simply looking to onboard new schools, or if your schools do not care about preserving historical data, this guide may not be relevant to you. If you are planning to migrate more than 50 existing districts or universities, please reach out to our support team to discuss your use case.
Defining "Migration"
What we are calling "migration" in this context is the process of mapping existing data entities (users, classes, assignments, etc) to their corresponding entities in Edlink. Whether you're moving from an existing integration, a homegrown solution, or a third-party system, the goal is to ensure that all relevant data is preserved and accessible in your platform after completing your Edlink integration.
In reality, there's really no data "moving" happening here. Instead, you're just making sure that everyone's identifiers are aligned between your system and Edlink. This way, when Edlink sends you data about a person or class, you can match it up with the corresponding data in your system.
Choosing What to Migrate
The most impactful data to preserve is typically user account objects. What this means is that when existing users (students, teachers, admins, etc) sign into your product via your Edlink integration, their data is still available (the same way it was before the Edlink integration).
Most companies can get away with just migrating user accounts (if they time the migration correctly), but you may also consider migrating class data. Typically, anything beyond that (assignments, grades, etc) is not worth the effort to migrate, or it is senseless to do so because it may not make sense for the data to exist in the newly-integrated system. For example, if there are assignments in your system and you just built a Google Classroom integration via Edlink, there will likely be no "migration" that has to happen because the assignments never existed in Google Classroom to begin with.
Choosing When to Migrate
The timing of your migration can have a big impact on its complexity. The easiest time to migrate is typically during a school break (summer or winter break), when there are fewer active users and less data being generated. This minimizes the risk of data loss or inconsistencies during the migration process.
Executing the Migration
Ok, so you've decided to migrate an existing customer to your Edlink integration. Here's how to get started.
Identify a Customer to Migrate
- Start by identifying a school that is willing to work with you on the migration process. It's often helpful to start with a smaller school or district before tackling larger, more complex ones. In addition, it's helpful to have a friendly point of contact at the school who can help test and validate the migration.
- Have the school connect to your application via Edlink, following the standard onboarding process.
- Once the school is connected, you can begin the technical part of the migration process (described below).
Discuss Changes With the School
Typically, migrating to an Edlink integration will involve some changes for the school. For example, teachers may have used email & password to log into your product before, but now they will be using SSO via Edlink. It's important to communicate these changes with the school ahead of time, so they know what to expect. You may also need to provide some training or documentation to help them understand how to use the new integration if new functionality is available to them (e.g. grade sync).
Technical Migration Strategies
Here are a few different strategies you might consider. If you'd like to discuss your specific use case with our engineering team, please get in touch with our support team.
No Migration
If data continuity isn't important (or your product doesn't store much data), then you might just consider starting fresh with the new data. A great time to do this is over winter or summer break when schools are out of session and classes are changing anyway.
One Time Migration
This strategy involves the creation of a mapping table between your old data and your new data (or just the relevant entity IDs). You'll need to write a script to migrate the data from your old system to Edlink. This is often the simplest strategy, but it can be complex at scale (or if the data is scattered and disorganized). Edlink can often help with this process, providing assistance with the generation fo the mapping table.
The goal here is correctly associate objects in your database with their Edlink counterparts.
Continuous Migration
This isn't necessarily a migration, per se, but rather a strategy for keeping data in sync between your system and Edlink. This is often the most complex strategy in the long term, but it can be easier in the short term. Basically, you'll need to keep track of which data came from Edlink and which data came from your system. As you sync data from Edlink, you'll have to match it up on the fly with the data in your system.
For example, suppose you have an existing Google Classroom integration where you store users' Google IDs in your system. When you build an Edlink integration, you'll need to make sure that when you receive data from Edlink, you can match it up with the corresponding Google IDs in your system. This way, when a user signs in via Edlink, you can still find their existing data in your system.
This can be tricky: because we generally recommend that you use Edlink IDs as the primary identifiers in your system, you'll need to check both the Edlink ID and the Google ID of a user to find their data. This can lead to some complexity in your data model and sync logic, but it can be worth it if you need to preserve existing data and a one-time migration isn't feasible.