Replacing the spreadsheet is not the same as building a people operating model
Migration succeeds when the company defines groups, roles, ownership, policies, and validation, not merely field mapping.
Inventory the decisions, not only the columns
A spreadsheet migration can look clean and still fail. Names, titles, emails, managers, and start dates may import correctly while the operating model remains undefined. Who approves time off? Which site lead can edit profiles? Who may see compensation? Which group owns access requests?
Implementation should start with decisions, not only fields.
Define the target organization model
Groups, locations, reporting lines, roles, and lead scopes should be mapped before import. If the organization is ambiguous in the source system, importing it faster just preserves the ambiguity.
Perelan Implementation treats this as an operating-model exercise: scope, stakeholders, permissions, migration inventory, integration inventory, and launch success criteria.
Clean ownership and duplicates
Every imported field should have an owner. HR may own employment dates, finance may own pay history, managers may validate reporting lines, and IT may validate access ownership. Duplicate people and inconsistent emails should be resolved before they become permission problems.
Test permission views
Migration validation should include role checks. Employee, manager, HR, finance, and IT/Ops should each open real journeys with test data. The question is not just "did the value import?" It is "did the right person see the right value?"
Reconcile and sign off
A useful reconciliation report shows counts, warnings, resolved issues, and owner signoff. This is slower than pretending migration is one click, but it is how sensitive systems stay trustworthy.
Launch journeys, not just records
The launch should test requests, approvals, documents, access, surveys, and support paths. A people system becomes real when people can complete work inside it, not when the database is full.
Next step