Why an alumni Excel file dies in 18 months
An Excel file can handle 500 alumni for 2 years. Beyond that, three signals appear, always in the same order.
Signal 1: duplicates. After 3 years of existence, an alumni file typically contains 10 to 25% duplicates — same person, work email then personal email, last name that changes, class year that hesitates between entry year and graduation year. You no longer know who to send what to. A dues call goes out twice to the same alumnus: they complain, they unsubscribe, they tell others.
Signal 2: GDPR becomes unmanageable. An alumnus asks "delete me from your database". You open the Excel file, search through 12 tabs, find 4 rows concerning them, miss one, and they come back 6 months later CC'ing the regulator. Likewise, it's impossible to attest who consented to what, when, and for what purpose.
Signal 3: no self-service onboarding. A young graduate can't create their account, update their email, or change their address. Everything goes through you. At 2,000 alumni, you get ~15 modifications per week — or 6 hours per month of no-value work.
Excel is a transition tool, not a long-term management tool. When the alumni director receives a first formal GDPR request and has to search through 12 tabs, the signal is clear: migrate now.
Phase 1: Data audit (1 week)
Migrating without auditing means importing the mess into a clean platform. Result: the platform becomes messy within 6 months. The audit takes one week, no more.
Step 1: count what counts. Five numbers to produce, with simple Excel formulas:
- Total rows vs unique rows (key = email + name + class). Gap = duplicate rate.
- Bounce rate: emails that bounced in your last 3 campaigns. Typically 8-15% on an unmaintained base.
- Distribution by class year: how many alumni per graduation year. Reveals historical gaps (often classes < 2000).
- Distribution by country: useful if the migration concerns a diaspora community.
- Empty-field rate on critical fields (email, class, consent).
Step 2: classify fields. Three categories. Critical: last name, first name, email, class year, GDPR consent. Without them, the alumnus does not exist in the new base. Useful: city, phone, LinkedIn, professional status, sector. Optional: birth date, nickname, interests. Any migration must save 100% of critical fields and 80% of useful ones.
Step 3: spot the GDPR risks. Three things to check: missing consent (alumni never explicitly opted in), emails deactivated without formal unsubscribe, sensitive data stored without a legal basis (religion, health, political opinions — it happens more often than you'd think in association files).
Deliverable for phase 1: a 2-3 page audit report with these numbers and a risk map. It will serve as reference for the DPO and justify the platform budget.
Phase 2: Target schema (1 week)
Once the audit is done, you know what you have. What remains is defining what you want.
Mandatory fields (always): last name, first name, primary email, class year, degree (if multi-program school), GDPR consent status with timestamp. Five fields, no more. If an alumnus doesn't have those five, they don't pass — or they pass in "to complete" with a self-service follow-up email.
Useful optional fields: secondary email, phone, city, country, LinkedIn, current company, current role, sector. These fields are either filled at migration or completed by the alumnus themselves through their personal space — which is always cleaner and more legal.
Automatic enrichment. Two legal and effective sources: LinkedIn (via ToS-compliant scraping or approved APIs) for role / company / sector, and the SIRENE business registry for French companies (NAF code, headcount, location). A well-done enrichment fills 60-70% of optional fields without alumni intervention.
Structural choice: pre-structured or custom? A pre-structured platform (Terrilink, AlumnForce, Hivebrite) imposes a data model but guarantees maintainability. A custom build (Django + PostgreSQL) offers unlimited flexibility and costs €40-80k to build, then €15k/year to maintain. Recommendation: pre-structured unless an extreme case (federation of 15 associations with heterogeneous rules). For detailed trade-offs, our alumni software selection guide lists 10 decision criteria.
Phase 3: Import and deduplication (2 weeks)
This is the most technical phase, and the one where the final quality of the database is decided.
Import format. CSV UTF-8, comma separator, first line = headers in snake_case (email, first_name, last_name, promotion_year, etc.). Avoid XLSX as an import format: Excel reinterprets dates, strips leading zeros from postal codes, and turns some emails into hyperlinks. Clean CSV, always.
Deduplication rules. The de facto primary key of an alumnus is not their email (which changes) nor their name (which can change): it's the combination normalized_email + normalized_name + class_year. Two rows with the same key = merge. Normalization: lowercase, accents stripped, spaces trimmed. A secondary rule for ambiguous cases: if two rows have the same name + same class but different emails, tag as "merge candidate" and handle manually. Budget ~2 hours per 1,000 rows for manual merging.
Preserving dues history. If your Excel contains a dues history, mapping those columns to the new platform is critical. An alumnus who's been paying since 2015 should see their "10-year loyal" status appear on their profile — otherwise they feel dispossessed. Columns to map: dues year, amount, payment method, status. Ideally in a separate table (one row = one payment).
10% test import. Never, ever import everything at once. Always: a 10% sample including edge cases (alumni with 2 classes, alumni with 3 emails, deceased alumni, international alumni). Manually verify the first 100 rows imported. Fix the script or the mapping. Then run the full import.
Edge cases to anticipate: multiple emails (work + personal) — keep both but flag one as primary. Name changes (marriage) — keep "birth name" as a secondary field for findability. Deceased alumni — status "archived", not deleted (historical memory + compliance). And above all: never import bounces. An email that has bounced 3 times must be purged before import. Otherwise you poison the reputation of your new sending domain from the first campaign.
Phase 4: Launch without the "dead platform" syndrome
You have a clean, imported, structured base. If you send a mass email saying "here's your new platform", you'll get ~8% adoption and a platform that looks empty for 6 months. Here's how to avoid that trap.
Staged launch: 20-50 beta testers. Manual pre-selection: former association presidents, active mentors, long-time payers, passionate administrators. You contact them individually (no mass email), ask for 2 weeks of testing, fix the bugs they report. These 20-50 alumni become the ambassadors for the official launch.
First exclusive event within 30 days. Nothing worse than a platform whose home page shows "No events scheduled". Schedule an event (in-person or webinar) whose registration runs exclusively through the platform. Alumni must log in to exist at that event. Observed adoption: ~40% in 4 weeks vs 8% with mass email.
Integrate the platform into the critical path. Two flows to wire up as priority: annual dues (no other way to pay than through the platform) and, if you're CGE/CTI, the annual placement survey. Once the platform is positioned on those two flows, it becomes indispensable — see our analysis on CGE survey response rates.
Progressive communication. Week 1: beta testers. Week 3: past presidents, class representatives. Week 5: mass email with beta tester testimonials. Week 8: first exclusive event. Patience over 8 weeks beats a blown launch in 2 days.
Classic mistakes that tank the migration
Five mistakes come up in 80% of failed migrations. None is fatal, all cost 3 to 6 months of catch-up.
- Migrating without purging bounces. Dead emails poison your sender reputation from the first campaign. +5% churn in the first week. Purge before import, always.
- Not archiving the old Excel file. Keep a frozen copy for a minimum of 12 months, with date and responsible party. A GDPR dispute, an accounting audit, a question about an old payer: without an archive, you're blind.
- Launching in June-July. Alumni go on vacation, the platform stays empty until September. Launch in March, September, or January. Never summer.
- Forgetting admin permissions. Who sees dues? Who can edit profiles? Who exports the database? Define those 3 roles before launch. Otherwise you'll have an association president downloading the entire database "to check" and creating a major GDPR risk.
- Not briefing the DPO upstream. Migrating an alumni base is a data processing activity in the GDPR sense. The DPO (internal or external) must validate the process, the purposes, the retention periods. Without their validation, you can be blocked at launch. Our GDPR alumni directory checklist lists the 12 points to cover with the DPO.
A well-run migration takes 6 to 10 weeks, requires 0.3 FTE on the alumni team side, and produces a database usable for 5 to 10 years. For a structured alumni association, it's the best investment of the decade.