Prospect, applicant and alumni records consolidated into Salesforce without losing inquiry sources, application history or the consent choices students have already made.
In education, migration usually means retiring several departmental systems at once: an admissions CRM, event and inquiry spreadsheets, an advising tool, and a separate alumni or advancement database. We map each into a single person record on Salesforce, keep the student information system as the source for enrollment and academic data, and carry forward inquiry sources, application milestones and communication preferences. Duplicate people created when a prospect later became a student and then an alum are merged carefully, so recruitment attribution, advising notes and giving history all sit with one individual.
Education data follows a person through stages that different offices have historically owned. Admissions sees a prospect, the registrar sees a student, advancement sees an alum or a parent, and each office built its own records with its own identifiers. A migration has to reconcile those without letting one office overwrite another's data. Privacy rules add constraints, because student education records are protected under FERPA and some fields should never leave the student information system. Timing is tied to the academic cycle too. Moving admissions data during application deadlines or yield season disrupts the work that most needs clean data.
Inquiries, applications, admits and deposits from the legacy admissions tool become stage history on the applicant record, with the original source and entry term preserved. That lets enrollment leaders compare past cycles in Salesforce instead of exporting old reports, and it keeps attribution intact for recruiters planning travel and outreach for the next term. Deposit and melt data stay tied to the same applicant, so yield analysis runs from one record.
College fair scans, campus visit sign-ups and web inquiry exports are usually spread across spreadsheets with different column names. We standardize them, match against existing applicants and students, and load only records with a usable identity and a clear origin, so counselors are not chasing duplicate prospects created from the same event or the same inquiry form. Unmatched leftovers are summarized by source for reporting.
Where advisors have kept notes in a standalone tool, we migrate them as case or interaction records tied to the student, with author and date retained. Sensitive categories such as accommodations or wellness referrals are flagged during mapping so visibility can be restricted to the advising roles that are allowed to read them. Notes written in shared spreadsheets get the same review before anything is loaded.
Alumni, parents and friends of the institution often live in a separate advancement database. We match them to former student records, carry over contact preferences and relationship links, and bring giving summaries across while the gift processing system stays authoritative for receipts, pledges and the financial reporting that auditors review. Class years, degrees and reunion affiliations come across so volunteer and event planning can segment alumni accurately.
We sequence education migrations by office and by academic calendar. Admissions usually moves first, timed after a recruitment cycle closes, followed by advising and then advancement, since each later phase can match against people already loaded. The registrar or institutional research team confirms which identifier ties records together, typically the student ID from the student information system. Each office signs off on a test load of its own records. Data governance and privacy staff review field mappings for protected information before production loads begin, and every phase ends with reconciliation against the legacy system's own reports.
Student IDs, enrollment status and program data anchor the matching process. We load only the fields each office needs and leave transcripts, grades and financial aid detail in the system of record.
Submitted applications, checklist items and decision history are mapped to the applicant record, so admissions staff see the full application story after cutover without logging into the old tool.
Constituent IDs and giving summaries are matched to alumni records, while receipting, pledges and gift accounting remain in the system that finance already reconciles and audits.
Education records carry specific disclosure limits. Work with your registrar and counsel to decide which fields belong in Salesforce, who can see them, and what stays in the student information system. Mapping is the right moment to make those calls, before any student data is copied anywhere.
Prospects and alumni have opted in or out of email and text messages in the old systems. Carry those preferences across exactly and test them before any campaign runs, because a migration that resets consent can undo long-built trust with a single careless send to the wrong list.
Loading an old recruitment term alongside the live one can confuse dashboards and automation. Mark historical terms clearly, deactivate automation during loads, and confirm that no former applicant receives a status email triggered by a record that was only being migrated.
Yes, and it is often the right starting point because admissions has the clearest process and the most urgent reporting needs. The design has to anticipate later phases, though. We set up person records, identifiers and consent fields so advising and advancement data can join the same records later without restructuring what admissions already uses every day.
We usually load the cycles leaders still compare against, as summarized stage history on each applicant, and archive older detail. Inquiry sources and entry terms are kept so year-over-year reporting still works. Records of people who never applied and never engaged can often be left out entirely, which also reduces the personal data the institution holds.
Each system tends to create its own record, so one person can appear several times with different emails. We match on institutional ID first, then on name, birth date and address, and merge into one person with every relationship preserved. Uncertain matches go to a review queue for the offices involved rather than being merged automatically.
It should not expand access unless that is a deliberate decision. We map each office's current permissions to Salesforce profiles, permission sets and sharing rules, then test with real user roles before go-live. Advisors see advising data, recruiters see recruitment data, and protected fields stay restricted to the roles your registrar approves. Any intentional change in access is documented and signed off.
One onshore team with 150 Salesforce certifications, a Salesforce Consulting Partner since 2017.
A monthly brief for the people who own Salesforce, AI and revenue technology
What changed in Salesforce and AI this month, and what to do about it.
One email a month. Written by the consultants who deliver the work, not by a marketing team, for the leaders who make the technology decisions.
Consultant analysis, not vendor recaps. One click to leave.