Skip to content
UnionStack logo UnionStack

UnionStack blog · Union management software

Migrating from spreadsheets or legacy union software

Prepare, map, reconcile and cut over union membership and case data without losing the relationships that make records useful.

UnionStack organizational structure containing fake connected entities
A representative UnionStack structure using fake entities to validate target relationships before a production migration. Screenshot from the UnionStack 2.0 test environment using fake data.

Migrating from spreadsheets or legacy union software is not a copy operation. The source contains implicit definitions, duplicate records, historical workarounds and relationships that may be understood only by experienced staff. A controlled migration makes those assumptions visible before the destination becomes authoritative.

Define the first operating outcome

Choose what the first production release must support. Examples include dependable member lookup, current positions and organizational relationships, or active grievance management. A narrow initial outcome helps the team decide which data and history are required.

List what is explicitly out of scope. Deferring a domain is safer than importing it without an approved target model or owner.

Inventory every source

Union data may exist in databases, spreadsheets, shared drives, personal files, email systems, accounting tools and public websites. For every source, record:

  • business and technical owner;
  • format, extraction method and date;
  • record and file counts;
  • sensitivity and authorized users;
  • known quality problems;
  • retention and archival decision;
  • dependencies on reports or integrations.

Configure the target model before final mapping

Define representative people, entity, position and case types, fields, statuses and relationships in UnionStack. Test the model with a small branch of the organization and a realistic case before mapping every source column.

If the target is changing while mappings are being finalized, transformation rules will be reworked repeatedly and reconciliation will be harder to interpret.

Profile quality and duplication

Measure missing identifiers, inconsistent names, invalid dates, obsolete controlled values, duplicate people, orphaned positions and unreadable files. Do not treat matching record counts as sufficient quality evidence.

Build an exception register. Each issue should have a severity, owner, proposed disposition and approval status. Ambiguous duplicates should be reviewed rather than merged solely on name or email.

Create a source-to-target mapping

For every source field, document the target, transformation, default, controlled-value translation and exclusion reason. Include relationship mapping and stable identifiers, not only columns.

A workplace stored as free text may need to become an organizational entity relationship. A combined “Local / Bargaining Unit” column may need to be separated and reconciled. A case participant name may require resolution to the correct person record and participant role.

Rehearse with representative data

Use common and exceptional records. Include similar names, multiple positions, historical terms, inactive members, multi-entity relationships, open grievances, closed cases and documents with varied formats.

Run the same migration steps more than once. A repeatable process makes it possible to correct mappings and compare results before cutover.

Reconcile records and relationships

Compare counts by agreed population, not only a total. Sample critical records with operational users and validate:

  • people identity and current status;
  • position history and organizational relationships;
  • case type, requestor, participants, assignment and progress;
  • document integrity, name, provenance and relationship;
  • report definitions and totals;
  • integration identifiers and ownership.

Prepare cutover and rollback

Define the source freeze or change-control window, final extraction, migration sequence, validation gates, communications and responsibilities. Preserve a recoverable source and specify the conditions that would stop or reverse the cutover.

Do not retire the source immediately. Keep it controlled and read-only where appropriate until destination reports, integrations and priority workflows have stabilized and formal acceptance is recorded.

Support post-launch correction

Users will find issues after launch. Provide a correction path that captures the source problem, destination impact and approved resolution. Track recurring causes so the team can improve mappings, configuration or training.

Schedule early reviews of duplicates, missing relationships, invalid controlled values, access and integration errors. Assign ongoing owners rather than treating quality as a temporary project responsibility.

Evaluate migration during software selection

Give shortlisted vendors the same representative sample. Ask what is included, what requires services, what the union must clean, how documents and relationships are handled and what acceptance evidence will be produced.

Use the full UnionStack migration guide and checklist to structure inventory, mapping, rehearsal, reconciliation and cutover decisions.