Multi-campus alumni networks: one database, several identities

Three campuses, three files, three versions of the truth

The scene is nearly always the same. Leadership asks how many reachable graduates the institution has. The historic campus says 12,000. The second campus says 4,000 — but its file still contains students who dropped out mid-course. The newer Paris campus never kept a list at all; it relies on a LinkedIn group. Nobody can say how many duplicates exist across the three, or how many addresses are still valid.

This is not a discipline problem. It is the mechanical consequence of an organisation where each site started its network when it needed one, with whatever was at hand, and where no shared rule was ever set. Everyone is right locally; the institution simply has no consolidated figure to present.

And the cost does not stop at counting. An alumnus who spent a semester on two campuses receives two invitations to the same gala. A partner company is approached three times for the same sponsorship. A young graduate looking for a mentor in their field only sees alumni from their own site, while the right person sits on another campus. A fragmented database is a direct loss of value for the network itself.

What "multi-campus" actually covers: four configurations

Before choosing an architecture, name your own. These four configurations do not raise the same questions, and many institutions combine two or three of them.

• The historic multi-site institution. One institution, several long-established locations. Arts et Métiers is the textbook case: the school lists around fifteen locations — Aix-en-Provence, Angers, Bordeaux-Talence, Brest, Chalon-sur-Saône, Châlons-en-Champagne, Chambéry, Cluny, Laval, Lille, Metz, Paris, Saint-Étienne, plus Rabat — for 6,000 students and 2,000 graduates a year. The brand is shared, but alumni attachment usually forms at campus level.
• The merger. Two schools become one, and two alumni communities end up under a brand that did not exist when they graduated. NEOMA Business School was created in 2013 from the merger of Reims Management School and Rouen Business School, with campuses in Reims, Rouen and Paris; the same year, KEDGE Business School emerged from the merger of BEM in Bordeaux and Euromed Management in Marseille, with four French campuses.
• The university with faculties. A university whose faculties, institutes and internal schools each have their own culture — and sometimes their own alumni association. Université de Lorraine, created on 1 January 2012 from the merger of the Nancy and Metz universities, reports 40 teaching faculties across 51 sites. At that scale, a single directory is not a convenience: it is the only way to have an institution-wide figure at all.
• The international network. Campuses abroad, with their own constraints: interface language, time zones for events, and sometimes a local association under foreign law. KEDGE runs associated campuses outside France, and Arts et Métiers a location in Rabat.

The first three configurations raise a question of internal governance. The fourth adds a question of localisation — and both are solved with the same tooling, provided you told them apart first.

Why one database per campus costs more than it returns

The apparently simplest option — each campus keeps its own tool — is almost always the most expensive over three years. It multiplies four costs that are routinely underestimated at decision time.

The reconciliation cost. Every figure presented to the board has to be rebuilt by hand: export each database, deduplicate, arbitrate the ambiguous cases. That work is redone in full at every deadline, and it produces no reusable data.

The internal mobility cost. A student who changes campus mid-course, a double degree, a gap year: in a fragmented model these journeys create duplicates rather than richer profiles. Yet those are exactly the alumni the network needs most, because they know two communities.

The compliance cost. The data controller is the institution, not the campus. Three different tools mean three processing agreements, three retention policies and three rights-request procedures to keep consistent — and an erasure request that has to propagate everywhere. Our GDPR checklist for an alumni directory spells out what that means in practice.

The exit cost. Three contracts mean three renewal negotiations and three migrations to plan for the day you change tools — something to settle at signature, as we argue about data reversibility.

One database, organisational units: the rule that unlocks it

The principle is easy to state and politically hard to hold: a single database, split into organisational units. A unit is not a separate database — it is a structuring label carried by each profile and each piece of content: a campus, a faculty, a founding school, an overseas chapter.

That split changes everything, because it separates two things the fragmented model conflates: belonging and visibility. An alumnus belongs to the Rouen campus; that says nothing about what they are allowed to see. An event is organised by the Bordeaux campus; that says nothing about who should hear about it. Once those two planes are separated, edge cases stop being manual exceptions: the double-degree graduate carries two units, the alumnus of a merged school carries their founding school and the current institution.

Technically, this means the tool must do three things: carry several units on one profile, filter the directory and the statistics by unit, and delegate administration within the scope of a unit. That is exactly what organisational units in an alumni platform are for — and it is the first thing to check in a demo if your institution has more than one site.

Who sees what: four decisions to write down before choosing a tool

These four trade-offs belong to leadership, not to the vendor. Settling them in writing before the demos stops a piece of software from imposing a policy by default.

1. Directory visibility. Does an alumnus see the whole institution, or only their campus? The default answer should be "the whole institution": that is the entire point of a merger or a multi-site school. Restrictions mainly make sense for executive programmes or sensitive cohorts, and should stay a documented exception.
2. Administration scope. Who creates an event, approves a registration, publishes an announcement, sends a mass email — and over what scope? The model that lasts gives each campus a local administrator over its own unit, and reserves institution-wide scope for a small central team.
3. Default targeting of communications. This is the setting that does the most damage when left to chance. An evening event in Lille has no business appearing in the feed of alumni in Marseille; the annual membership call, on the other hand, concerns everyone. Decide the default, then allow widening explicitly.
4. Who is the data controller. The institution is the controller; alumni associations, when they are separate legal entities, have their own status. Map this with your DPO before migration, not after.

After a merger: two histories, one directory

A merger adds a difficulty a multi-site institution never faces: the alumnus's degree carries the name of an institution that no longer exists. Someone who graduated from Rouen Business School in 2005 does not think of themselves as "a NEOMA alumnus" — they are an RBS alumnus, and their network, their memories and their original association carry that name.

The classic mistake is to settle it one way or the other: either you erase the founding school in the name of a single brand, and you lose the attachment — hence the dues and the participation; or you keep two separate directories "for the duration of the transition", and that transition never ends.

The workable answer is to treat the founding school as an attribute of the graduating class, in the same way as the year or the programme. The profile reads "Rouen Business School, class of 2005"; the directory filters by founding school as much as by current campus; and consolidated institution figures add the two histories together without merging them into one. Alumni associations of the founding schools can then keep existing as units in their own right, with their own events and their own communications, inside a shared directory.

This is also the moment to revisit profile status. A merger migration is the ideal opportunity to clean up graduates who have been tagged "student" for years — an extremely common defect we cover in our article on the automatic student-to-alumni switch.

Reporting: consolidate without flattening the detail

A multi-campus institution permanently needs two levels of reading, and most setups produce only one.

The institution level serves the board, the rankings and institutional communications: reachable graduates, event participation rates, membership income, value created by the network. The unit level is what you actually steer with: it is where you see that a campus is slipping, that a faculty has stopped organising anything, or that an entire cohort has never been contacted.

This dual reading is not a luxury: graduate employment reporting is filed per degree, not per institution. A database that cannot segment by campus and by programme forces you to redo the split by hand for every campaign — precisely the work that makes the CGE survey calendar unmanageable when two campaigns overlap. The graduate employment survey module only produces usable exports if the segmentation already exists upstream, in the structure of the database.

To pick which indicators to track at each level, our article on the 7 KPIs of an alumni network is a starting point; simply break each of them down by unit alongside the institution-wide total.

Structuring a multi-campus alumni network in 5 steps

1. Inventory what exists before looking at any tool. How many files, held by whom, with which fields, how fresh, and how many likely duplicates. That is one to two weeks of work that determines everything else — and it matches the approach in our guide to migrating from Excel.
2. Draw the map of units. Campuses, faculties, founding schools, overseas chapters. One line per unit, with a named owner. If you cannot name who runs a unit, it does not exist yet.
3. Settle the four permission decisions, in writing. Visibility, administration, default targeting, data controllership. One page is enough — but it must be signed off by leadership and by the DPO.
4. Migrate with the unit of origin as an attribute. Every imported profile carries its campus, its faculty and, after a merger, its founding school. That field is hard to backfill later: it is now or never.
5. Roll out gradually, starting with a pilot campus. One willing site, one cohort, one real event. Governance friction shows up after three weeks of use, never in a scoping meeting.

The technical baseline you need

Once those decisions are made, the requirement on the tool becomes easy to state. It must carry several units on one profile, filter the directory and the statistics by unit, delegate administration to a scope, target a post or an email at one or more units, and produce the segmented exports accreditation bodies expect. A directory kept in a spreadsheet ticks none of these boxes, for the reasons we set out in our comparison of Excel versus a dedicated platform.

Priorities differ by institution type: a university first needs to absorb its faculties, a multi-site engineering school needs to segment employment tracking per degree, and a business school born from a merger needs to preserve attachment to the founding schools while consolidating its brand.

In short

Method and sources. The institutional configurations cited come from public sources: Arts et Métiers list of locations, Université de Lorraine key figures (40 teaching faculties, 51 sites), KEDGE Business School history. These institutions are cited as illustrations of organisational configurations; they are not Terrilink customers and the mention implies no commercial relationship. The rest of the article describes an organisational method drawn from our practice: we deliberately put forward no unverified market figures. For the precise requirements of an accreditation body, refer to its current standards (CGE, CTI).