When a UK university decides to replace its student recruitment CRM, the conversation starts with platform selection. It almost always should start with data migration.

Platform choice matters, but a wrong migration strategy can undermine the best platform selection decision. Legacy student data held in systems like Gecko, which is one of the most widely used student engagement and event management platforms in UK higher education, carries years of prospect history, event attendance records, email engagement signals, and interaction logs. If that data does not transfer correctly into the new CRM, the institution goes live on a platform that looks empty, produces unreliable analytics, and cannot support the personalised engagement journeys the entire project was designed to enable.

The CRM data migration industry has a well-documented failure problem. Studies consistently show that the majority of data migration projects exceed their timelines or fail to meet their original scope. Post-migration cleanup costs between three and ten times more than cleaning the same data before the move. And up to 40 percent of CRM migrations encounter significant problems ranging from data integrity failures and duplicate bloat to field mapping errors that silently corrupt analytics reporting.

Higher education migrations add unique complexity. Student data does not follow a simple contact-to-account hierarchy. One applicant may have multiple applications across different cycles, different courses, and different intake years. Event data is relational, linking prospects to sessions, registrations, attendance, and follow-up interactions. Email engagement history contains open and click data that feeds directly into lead scoring models. And Banner, the authoritative student record system at many UK universities, must remain the source of truth throughout and after the migration without risky write-back configurations introducing conflicting data.

This playbook covers how to approach a Gecko migration correctly: what data to extract, how to structure it, where deduplication must happen, how to handle the Banner relationship, and what a zero-loss migration to Microsoft Dynamics 365 actually looks like in practice.

3-10x

The cost premium of post-migration data cleanup compared to cleaning records before the move. Pre-migration investment is always cheaper.

40%

Of CRM migrations encounter significant problems: data integrity failures, duplicate records, or field mapping errors that corrupt reporting.

83%

Of data migration projects overall fail to meet their original scope, exceed budget, or disrupt operations according to widely cited industry analysis.

Understanding What Gecko Actually Holds

Before any migration plan can be built, the team needs a precise inventory of what Gecko contains. Gecko is not a CRM in the traditional sense. It is a student engagement platform built around events, communications, and chatbot interactions. What it stores reflects that purpose, and the data it produces is structured differently from how a CRM like Microsoft Dynamics 365 organises its data model.

A typical Gecko environment at a UK university will hold the following data categories, each of which requires a distinct migration approach.

Prospect Records

Gecko holds profiles of prospective students who have interacted with the institution through its event registration pages, chatbot, or communication campaigns. These records include contact details, course interests, geographical information, and engagement metadata. The critical challenge is that Gecko prospect records are not deduplicated in the way a full CRM would manage them. The same individual may exist as multiple records across different event registrations, particularly if they changed their email address between interactions or registered via different channels.

Event Records

Events are a first-class data object in Gecko. An open day, a virtual campus tour, a subject-specific webinar: each is a distinct event with its own registration list, session structure, capacity, and attendance record. The relational structure here is: Event contains Sessions. Sessions contain Registrations. Registrations link to Prospect records and carry attendance status, booking time, and any custom fields the institution configured. This hierarchy must be preserved in the target CRM. Flattening it during extraction means losing the ability to report on which events influenced which outcomes.

Email Engagement History

Gecko records message send, delivery, open, and click data for campaigns run through its platform. This engagement history is the raw material for lead scoring in the new CRM. A prospect who opened multiple course-specific emails over six months and clicked through to a prospectus download is a materially different lead from one who received the same emails and never engaged. Losing this history on migration means the new CRM launches with a flat, unscored prospect database in which all records look the same, regardless of their actual conversion potential.

Interaction Logs

Chatbot interactions, call centre records, and manual notes captured through Gecko's engagement tools form a longitudinal interaction history. For established prospects, this history can span multiple recruitment cycles. It informs both personalisation decisions and the completeness of the 360-degree student view the new CRM is designed to provide.

The same individual may exist as multiple records across different Gecko event registrations. Deduplication is not a cleanup step. It is a pre-condition for a usable migration.

The Deduplication Imperative

Deduplication is the single most important activity in any CRM migration, and it is consistently the most underestimated. Simple exact-match deduplication on email address is not sufficient. Real-world duplicate records in a student engagement platform are fuzzy: the same student may appear as 'Joe Bloggs' with one email address from a Year 12 open day registration, and as 'Joseph Bloggs' with a different personal email from a university application form submitted eighteen months later.

Fuzzy matching logic must be applied across multiple attributes simultaneously: name variants, email address, date of birth where available, postcode, and phone number. A matching score is calculated across these attributes and records above a defined threshold are flagged for merge. The merge process must then apply survivorship rules: deciding which version of each attribute to retain in the surviving record and how to consolidate the interaction histories from both records into a single coherent timeline.

For a Gecko migration into Dynamics 365, deduplication should run in three distinct stages. The first is pre-extraction profiling within Gecko itself, identifying the scale of the duplication problem before any data leaves the source system. The second is pre-load deduplication on the extracted dataset, before any records are written to the new CRM. The third is an ongoing real-time deduplication rule configured within Dynamics 365, applied during and after the Banner integration sync to prevent new duplicates being created at the boundary between systems.

SURVIVORSHIP RULES: A DECISION THAT MUST BE MADE BEFORE MIGRATION BEGINS

When two Gecko records are identified as the same individual, the merge must produce a single surviving record. Which email address takes precedence? Which name format is retained? Are all interaction records appended to the survivor? Are all event attendance records preserved? These decisions must be documented in a survivorship rule specification before any migration tooling is configured. A migration that reaches this point without agreed survivorship rules will stall or produce inconsistent results that require manual remediation. VE3 builds survivorship specifications as a formal discovery output, signed off by recruitment and data governance stakeholders before extraction begins.

The Banner Relationship: What Must Not Change

For universities using Ellucian Banner as their student record system, the migration must be designed around a single governing principle: Banner is the authoritative source of record for applicant and student data. The new CRM does not overwrite Banner. Banner does not write to the CRM automatically without authorisation. And during migration, no data from Gecko should be allowed to create or modify Banner records.

The practical implication is that the migration must establish clear data ownership boundaries from the start. Gecko holds prospect and engagement data. Banner holds confirmed applicant and academic data. The new CRM holds the unified engagement view, consuming data from both systems but overwriting neither without a governed, explicit synchronisation event.

Where a prospect in Gecko has progressed to become an applicant in Banner, the migration must reconcile those two records into a single CRM contact. The Banner record provides the authoritative name, applicant identifier, and academic data. The Gecko record provides the engagement history, event attendance, and marketing interaction data. The CRM contact is the union of these two, structured so that future Banner sync events update the authoritative fields without overwriting the engagement history.

This reconciliation step is frequently underestimated in scope. At a university with an active recruitment operation, the overlap between Gecko prospects and Banner applicants may run to tens of thousands of records. Each one requires a match-and-merge operation that preserves the engagement history while anchoring the record to the authoritative Banner identity.

WRITE-BACK GOVERNANCE

The migration design must specify what happens when a CRM user updates a field that Banner also owns. The correct architecture is a flag-and-review workflow: the CRM records the proposed change, flags it for authorised staff to review, and only updates Banner when that review is completed and approved. Automatic write-back without a review gate is a data governance risk. It introduces the possibility that a data entry error in the CRM cascades into the authoritative student record, affecting admissions, correspondence, and potentially a student's application status.

The Five-Phase Migration Approach

A Gecko migration to a new HE CRM is not a single event. It is a phased programme of work, each phase with defined inputs, outputs, and sign-off criteria. The phases cannot be reordered without increasing risk.

PHASE 1: DATA AUDIT AND PROFILING

1. Extract a representative sample from Gecko: prospect records, event structure, email engagement, interaction logs.

2. Profile the dataset: record counts by entity type, duplicate estimate, completeness by field, date range of records.

3. Identify Banner overlap: match Gecko prospect identifiers against Banner applicant identifiers to size the reconciliation scope.

4. Document data quality issues: inconsistent formats, empty required fields, orphaned records, broken relational links.

5. Produce a Migration Scope Document: what will be migrated, what will be excluded, and the business justification for each decision.

PHASE 2: DATA MODEL MAPPING AND SURVIVORSHIP DESIGN

6. Map each Gecko entity (Prospect, Event, Session, Registration, Message, Interaction) to its equivalent Dynamics 365 entity.

7. Define field-level mapping: source field to target field, with transformation rules where formats differ.

8. Design the one-applicant-to-multiple-applications data model in Dataverse that reflects the university's actual recruitment structure.

9. Define survivorship rules for all duplicate merge scenarios, signed off by data governance stakeholders.

10. Define consent status migration: how Gecko opt-in and opt-out records map to Dynamics 365 consent attributes and GDPR compliance fields.

PHASE 3: PRE-MIGRATION CLEANING AND DEDUPLICATION

11. Apply fuzzy matching across Gecko records using name, email, date of birth, and postcode attributes.

12. Merge confirmed duplicate records according to survivorship rules. Document merge decisions for audit purposes.

13. Standardise data formats: names to title case, phone numbers to E.164, postcodes to standard UK format.

14. Purge records outside the agreed retention scope: prospects with no engagement beyond a defined historical cutoff.

15. Validate Banner reconciliation matches: confirm that Gecko-Banner overlap records can be cleanly merged without data conflict.

PHASE 4: MIGRATION EXECUTION AND VALIDATION

16. Load parent objects first: Contact records before Event records, Event records before Session records, Sessions before Registrations.

17. Run in test environment first. Execute at least three test migration cycles, each validating record counts, relational integrity, and field completeness.

18. Run Banner integration in staging: confirm that Banner sync events update the correct fields and do not overwrite engagement history.

19. Execute reconciliation report: compare source record counts against target record counts by entity type. Variance must be within agreed tolerance and fully explained.

20. Conduct UAT with recruitment and marketing staff: verify that a sample of known prospect records appear correctly in Dynamics 365 with complete engagement history.

PHASE 5: GO-LIVE CUTOVER AND POST-MIGRATION GOVERNANCE

21. Schedule cutover ahead of peak recruitment activity, not during clearing or application deadline periods.

22. Run delta migration: capture any new or updated Gecko records created during the testing period and load them into Dynamics 365 before go-live.

23. Decommission Gecko data writes: switch event and engagement data capture to Dynamics 365. Confirm Gecko is in read-only mode post-cutover.

24. Activate real-time duplicate detection rules in Dynamics 365 to prevent re-accumulation of duplicate records.

25. Run 30-day post-migration monitoring: track data quality metrics, flag anomalies, and confirm Banner sync is operating correctly.

Email Engagement History: The Migration Most Teams Skip

Email open and click history from Gecko's campaign platform is frequently deprioritised in migration scopes because it is harder to migrate than contact records and because its value is not always immediately visible to procurement and IT stakeholders. This is a significant mistake.

Email engagement history is the foundation of lead scoring in the new CRM. Without it, every prospect in the migrated database starts with a score of zero, regardless of how actively they engaged with the institution over the previous twelve or twenty-four months. The marketing automation journeys and AI-driven personalisation that justified the CRM investment cannot function without this signal data in the first place.

The migration of email engagement history requires mapping Gecko message records to Dynamics 365 email activity records and attaching them to the correct contact via the reconciled identifier. Open events and click events are logged as interaction records. The aggregate engagement score is then recalculated in Dynamics 365 based on the migrated history. This is not a trivial operation at scale, but it is the operation that makes the day-one analytics dashboard meaningful rather than empty.

THE DAY-ONE ANALYTICS ARGUMENT

A university that has run Gecko for three years has three years of prospect engagement data. If that data is not migrated, the new CRM is analytically blind for the first twelve months while it accumulates enough new engagement history to produce meaningful scoring signals. For a recruitment operation that invested in a new platform specifically to improve conversion rates and personalisation quality, a twelve-month blind period is an expensive consequence of an avoidable migration decision.

Consent Status Migration: A GDPR Requirement, Not an Optional Step

UK GDPR requires that consent records be specific, timestamped, and tied to a defined purpose. Gecko holds consent and opt-in status for the prospects in its database. During migration, those consent records must be transferred to Dynamics 365 with full fidelity: not just the binary opt-in flag, but the timestamp of consent, the channel it applies to (email, SMS, WhatsApp), and the purpose category.

A migration that imports contact records without their corresponding consent status creates an immediate compliance risk. Staff using the new CRM have no visibility of whether a prospect has consented to marketing communications. Campaign tools may include records that should be suppressed. And the institution cannot demonstrate to the ICO, in the event of a complaint, that consent was properly carried forward during the system transition.

Consent migration must be explicitly scoped in the migration plan, not treated as a field mapping exercise. The consent data model in Dynamics 365 must be configured to receive and store this data before migration begins. The preference centre must be live and reading from the Dynamics 365 consent record before the first campaign is sent from the new platform.

What Zero-Loss Migration Actually Means

The phrase zero data loss is used widely in migration proposals. It is worth being precise about what it means and does not mean in an HE CRM context.

Zero data loss does not mean that every record currently in Gecko is transferred unchanged to Dynamics 365. Some records will be merged during deduplication. Some will be excluded because they fall outside the agreed retention scope or because they lack the minimum data quality to be useful. A prospect record with only a first name and no contact details cannot be used for engagement and has no place in the new CRM.

Zero data loss means that every record within the agreed migration scope is transferred completely and accurately: all fields populated, all relationships intact, all engagement history attached to the correct contact, and the aggregate record count reconciled and signed off against the source data. It means that no record is silently dropped during extraction, transformation, or loading without being captured in the reconciliation log and reviewed by the project team.

Achieving this requires a reconciliation report as a mandatory migration deliverable, not an optional quality check. The report compares source counts to target counts by entity type, explains every variance, and is signed off by the data governance lead before go-live is authorised.

Common Failure Modes in Gecko Migrations

Understanding where migrations typically fail is as important as knowing the correct approach. The following are the most common failure patterns in Gecko-to-CRM migrations at UK universities.

Deduplication deferred to post-go-live

Teams that skip pre-migration deduplication because it is time-consuming will go live with a CRM that contains thousands of duplicate records. These duplicates generate contradictory engagement signals, inflate campaign audience sizes, and undermine lead scoring accuracy. Cleaning post-migration costs significantly more in both time and effort than doing it before extraction.

Flat migration of relational data

Extracting Gecko event data as a flat file and loading it without preserving the Event-Session-Registration hierarchy destroys the reporting value of the data. The institution can no longer answer the question of which open days drove which applications, because the relational structure that enables that analysis no longer exists.

Banner reconciliation skipped or deferred

Treating the Gecko migration and the Banner integration as separate workstreams that will be joined later is a common and costly decision. When Banner sync goes live on a CRM that already has Gecko contacts loaded without Banner reconciliation, duplicate contacts are created at scale: one from the Gecko migration, one from the Banner sync, representing the same individual.

Consent data treated as optional

Migrating contact records without consent status means the new CRM cannot demonstrate compliance from day one. This is not a configuration issue. It is a legal exposure that cannot be remediated by updating records after the fact.

No delta migration before cutover

A migration that runs its final load weeks before the cutover date will go live with stale data. Any Gecko activity between the last migration run and the cutover creates a gap. The delta migration, capturing all changes since the last full load, is the step that ensures the CRM reflects the current state of the source data at the moment the new platform becomes the system of record.

LESSON FROM COMPARABLE HE IMPLEMENTATIONS

At a comparable UK university engagement hub implementation, early validation of Banner data views and a structured champions network were identified as the two biggest accelerators of go-live success and staff adoption. Both were built into the migration and change management plan from discovery, not added reactively. Banner validation in particular resolved a significant number of reconciliation ambiguities before migration execution began, eliminating the need for manual remediation during the cutover window.

In Summary

A Gecko migration is not a data transfer exercise. It is a data architecture decision that determines whether the new CRM is analytically credible on day one or analytically blind for the first year of operation.

The organisations that get this right are the ones that treat deduplication, Banner reconciliation, consent status, email engagement history, and relational data integrity as non-negotiable migration requirements rather than optional enhancements. They run phased migrations with formal sign-off gates, reconciliation reports, and UAT that involves actual recruitment staff reviewing actual records.

The cost of getting it right is borne during the project. The cost of getting it wrong is borne during every recruitment cycle that follows.

Every university switching its student recruitment CRM is making a multi-year commitment to a new platform. The data that migrates into that platform on day one sets the baseline for everything that follows. It deserves the investment and the rigour that an institution would apply to any other strategic infrastructure decision.

ABOUT VE3

VE3 is a UK-based enterprise AI and data technology consultancy specialising in Microsoft Dynamics 365 student recruitment engagement hubs for higher education. Our migration methodology covers Gecko prospect and event data, Banner reconciliation, consent status transfer, email engagement history, and post-migration duplicate governance, all delivered with zero data loss as a contractual commitment. We have delivered comparable HE migrations at scale, with outcomes including zero records lost and 100 percent of Clearing sends delivered on embargo from day one.