Why HR system consolidation after a merger is a different problem
After a merger, the core question is how to move two workforces onto one self-hosted HR platform without interrupting pay or losing the records that must survive. Frappe HR (part of the Frappe and ERPNext stack), OrangeHRM and Odoo are the usual candidates. Which one fits depends less on feature lists than on payroll localization for each country where employees sit and on whether the payroll rules you need are available in the edition you can run. Odoo's payroll and advanced HR functions, for example, are tied to edition choices that must be confirmed against the current Odoo pricing and edition pages before you commit, and Frappe HR's payroll coverage should be checked against the countries in your combined workforce.
The target system is rarely the hard part. The difficult work is the cutover sequence: which employee master records are mapped first, how leave balances and contract terms carry across without double counting, which pay period is the first one run on the new platform, and how employees are told what changes and when. Each of these decisions has a payroll consequence. Run the sequence in a test copy of the new system, reconcile the first live pay run against the old one line by line, and agree the freeze date for changes in the old system in writing before data loads begin.
The old system also takes on a new role. Once payroll moves, the legacy HR and payroll database usually becomes the place where historical pay and employment records are kept for retention and audit. Confirm with your legal and tax advisers which records must remain accessible, for how long, and in what format, then decide whether the old system stays online in read-only mode, is archived to an export, or is retired after a verified copy. Scope these decisions early, because the retention plan determines hosting, backup and access controls for a system that no longer runs payroll.
Which regulations and controls shape the consolidation
This table maps each regulation or control that can reach an HR consolidation to its source and to what it changes in the build, such as change control over migration scripts and documented cutover controls. Read it by first confirming which rules apply to the acquirer and the target, since the same HR data can fall under several regimes at once.
| Requirement or control | What it asks for | What it means for the build |
|---|---|---|
| SEC ICFR guidance on newly acquired businesses | Management may exclude an acquired business from its ICFR assessment for no more than one year from the acquisition date and not across more than one annual report, with the exclusion and its significance disclosed | Plan the HR cutover inside that window so payroll-related controls on the target are assessed on the acquirer's timetable, and document which target HR controls were excluded |
| Release 33-8810 IT general control areas | Names program development, program changes, computer operations and access to programs and data as example IT general control areas, limited to controls addressing financial reporting risk | Apply change management to migration scripts, mapping tables and payroll configuration, and keep access to the old and new systems under separate, logged approvals |
| 17 CFR 229.106 third-party oversight | Registrants must describe in annual reports how they oversee cybersecurity risks from third-party service providers | If the consolidated HR platform is hosted or supported by an outside party, keep due diligence, access terms and incident notice clauses on file before data moves |
| GDPR Articles 28 and 30 | Processors act only on documented controller instructions, and processing records describe security measures where possible | Write down the migration instructions given to any implementation partner, and update the records of processing to name the surviving HR system and the retired one |
| Chapter V transfers to a non-EEA acquirer | Under EDPB Guidelines 05/2021, remote access to EU personal data from a third country, including for support, is a transfer needing a Chapter V transfer tool | Restrict acquirer staff in other countries from viewing EU employee records during due diligence and integration, or put a valid transfer tool in place first |
| DORA Article 28 for regulated financial acquirers | Financial entities keep a register of ICT service arrangements and tested exit strategies and transition plans for services supporting critical or important functions | If the acquirer or target is a regulated financial entity, record the HR and payroll platform in the register and include the retired system in the exit and transition plan |
| EU Data Act switching rules | Where the old provider is a cloud data processing service, switching support, a maximum two-month notice period, a 30-day transitional period, data porting and no switching charges from 12 January 2027 apply (Regulation (EU) 2023/2854) | Confirm the contract terms of any cloud HR provider being retired and request an exportable data set, since porting rights shape the timing of the cutover |
| Records retention for the retired system | Retention duties continue after the migration, so the old system or an archive must answer for records the rules require | Decide whether the old HR system is kept read-only or its records are exported to an archive, and test that a sample of retired records can still be retrieved |
Employee master data, leave and contracts that must map across two companies
The first decision in a merger HR consolidation is which employee record is the source of truth for each data object, and that decision has to be made object by object before any data moves. The objects that need reconciling are employee identifiers and legal entity assignments, job and grade structures, contract terms, leave types and accrual rules, leave balances at cutover, payroll components and tax registrations, and manager hierarchies. Each one has a different owner on each side of the merger, and each one breaks differently when it is wrong. Two error sources dominate in practice: duplicate employees who exist in both systems under different identifiers (often because contractors, rehires or people transferred between the two companies were entered twice), and conflicting leave policies where the same leave name means different accrual rules, carry-over limits or approval chains in each company.
In a self-hosted platform such as Frappe HR on ERPNext, the mapping work lands in concrete places: the employee identifier used across Employee, Salary Structure Assignment and Leave Allocation records, the Company field that assigns each person to a legal entity, the Designation and Grade structures, and the reports-to hierarchy that drives leave approval. Build a crosswalk table that maps each legacy identifier to the new one, and mark every record that matches on name or national identifier in both systems for manual review. Leave balances need a decision on whether they are migrated as opening allocations or recalculated from accrual rules, because the two produce different numbers when policies differ. Confirm which leave types survive, how carry-over caps are applied, and who signs off each exception before any allocation is loaded.
Batch planning follows from the tool limits. The ERPNext Data Import tool supports CSV or Excel templates and imports child table rows, but its documentation advises importing only a few thousand records at a time. For a large combined workforce, split each object into ordered batches, run them in a non-production copy first, and reconcile counts and totals per batch against the source extract before the next one starts. Ask your implementation partner to show the batch sequence, the reconciliation report for each object, and the rollback step if a batch fails. Payroll components and tax registrations should be loaded and checked against the last closed payroll run in the old system before any employee is paid from the new one.
Which open source HR platforms fit a merger consolidation
After a merger, the acquirer and target usually run different HR stacks, so the platform choice depends on what each side already runs, which edition the license and support terms require, and how far the target's payroll and records must stay reachable. The cards below compare three options against those constraints.
Frappe HR on ERPNext
Frappe HR runs on the Frappe Framework and is typically deployed with ERPNext. ERPNext is licensed under GPL-3.0 and the Frappe Framework under MIT, so self-hosting carries no license fee. Confirm which major version each side runs before choosing, because version 14 reached end of life on January 31, 2026. Warranty coverage from Frappe requires a listed version and a matching Frappe Cloud support plan, so confirm whether you need that subscription for a self-hosted consolidation. Ask the partner which payroll localization your countries need, since this is not covered by the base platform.
Odoo Community edition
Odoo Community is published under LGPL-3.0 and gives you the open source core without a subscription. For a merger, the gap is operational: the upgrade service and on-premise use require an Enterprise subscription, and the Community edition has no access to the upgrade service. Plan for how two employee datasets will be upgraded and maintained after cutover. Confirm whether your HR and payroll modules are in the Community edition or depend on Enterprise features before you commit.
Odoo Enterprise on-premise
Odoo Enterprise adds the upgrade service, mobile apps and support, and it is the route to self-hosting with the upgrade path intact. On the pricing page, only the Custom plan can be hosted on Odoo.sh or on-premise, and only Custom includes multi-company, Odoo Studio, external API access and custom modules. A merger often needs multi-company structures for two legal entities during transition, so the Custom plan is the likely fit. Ask for the per-user cost in a written quote and compare it against the self-hosted Frappe option.
OrangeHRM when already in place
OrangeHRM is a sensible option only when the acquirer already runs it, because adopting a second HR platform during a merger adds migration and training work without removing the target's systems. Extending the existing instance lets the target workforce join without a new platform decision. Confirm that the version and modules cover the target's leave policies, shift rules and payroll inputs, and check whether the target's records can be imported without manual rework. Verify OrangeHRM's current release and licensing with the vendor before relying on them.
How a merger HR consolidation is rolled out in phases
The sequence moves two workforces onto one self-hosted HR platform in controlled stages, so each stage produces evidence that the next one can rely on. Payroll cuts over only after parallel runs have been reconciled, and the old system is kept as a retrievable archive for records retention.
Map entities, owners and systems of record
Discovery starts with the legal entities, countries, payroll providers, identity sources and HR systems on both sides of the merger. Your HR lead, payroll owner, IT and counsel for each entity confirm which system holds the authoritative record for each data type. The output is an entity and system inventory signed off by both HR teams, which defines the scope of every later step. Confirm early whether any acquired workforce sits under a different employing entity, because that changes contracts, payroll runs and reporting.
Harmonize target design and HR policies
Before any data moves, the combined organization decides the target company structure, leave types, accrual rules, working time patterns, approval chains and role-based access model. Policy owners, works council or employee representatives where applicable, and legal review the differences between the two policy sets. The output is a target design document and a policy decision log that states which rules apply to legacy employees on transition and for how long. Where a rule cannot be harmonized at go-live, record it as a documented exception so the data model can represent it.
Profile source data and write mapping rules
The implementation team profiles employee master data, contracts, leave balances, compensation components and documents from each source system. Data owners resolve duplicate employee IDs, inconsistent job codes, missing dates of hire and conflicting leave entitlements. The output is a signed mapping specification with field-level rules, transformation logic, default values and an exceptions register. Leave balances and contract terms should be mapped with the same rules used for the reconciliation report in a later step, so the two cannot drift apart.
Run test migrations into a non-production copy
Data is loaded into a non-production instance of the target platform, using the mapping specification and the import tooling the platform supports. Batch sizes should be small enough for the import tool's documented limits, and each run is logged with record counts, rejected rows and reasons for rejection. Business owners check sample records, and the team repeats the load until rejected rows are explained or fixed. The output is a reconciled leave balance report and a test migration log that shows record counts by entity and data type. Test copies should have personal data handled under your own privacy controls.
Run employee consent and notice workflow
Employees receive written notice of the change, what data moves, where it is stored, who can access it and how they can raise corrections before cutover. HR, legal and the data protection lead confirm the lawful basis, any consent requirements for each jurisdiction and the channel used for notice. Employees review their migrated profile, leave balance and contract details through a confirmation step. The output is a notice record for each population and a log of corrections received and closed. Confirm local requirements with counsel, because notice and consent duties differ by country and by works council arrangement.
Execute parallel payroll and variance review
Payroll runs in parallel, calculated in the legacy payroll process and in the consolidated platform for the same period and population. Payroll owners compare gross pay, deductions, taxes, leave adjustments and net pay employee by employee and investigate every variance above the agreed tolerance. Parallel runs repeat until the variances are explained and accepted. The output is a payroll parallel-run variance report with root causes, approvals and a go or no-go decision from the payroll owner and finance. Confirm the number of parallel cycles with your payroll provider and your own change governance, since no fixed count applies to every merger.
Cut over and freeze the legacy system
At an agreed cutover window, a final delta load brings the latest changes into the target platform, and the team reconciles headcount, active contracts, leave balances and open approvals. Once reconciliation passes, the legacy system is set to read-only for all users except the named archive team, and identity access is updated to match the new system of record. The output is a signed cutover checklist and a freeze confirmation with the time of the change. Keep a documented rollback path until the business accepts the cutover results.
Archive the legacy system and test retrieval
The legacy system is exported in a documented format, with its database, attachments, audit logs and configuration, and stored under your records retention schedule. Retention periods depend on the records and jurisdictions involved, so counsel and HR should set them before archiving. The team then performs a retrieval test, restoring a sample of records to a separate environment and checking that a named individual's file can be produced in full. The output is an archived export with a retrieval test report and an owner for the archive. Confirm with your auditors and counsel what evidence they expect for historic records.
When to cut over payroll: timing options and their trade-offs
A boundary cutover switches all payroll processing to the new platform at the start of a pay period, so the last run on the old system closes one period and the first run on the new system opens the next. Because no period is split between systems, the reconciliation is mostly a matter of confirming that the closing balances in the old system carry into the opening balances in the new one. The approach is common when both workforces are paid on the same calendar and the merger has a clear legal effective date.
- Reconciliation scope: Gross-to-net totals, tax withholdings, social contributions, deductions and net pay for the final old-system period must match the first new-system run for the same employees, using agreed tolerances.
- Year-to-date carry-over: Confirm that year-to-date earnings and tax withholding balances transfer, since tax filings depend on them.
- Sign-off: The payroll owner signs the final old-system run and the reconciliation, and the finance controller approves the bank file for the first new-system run.
- Failure mode: If the old system is not switched off or marked as closed for the employee population, both systems can generate payments for the same period, and recovering overpayments creates tax and employee relations problems.
- Calendar risk: Check the legal effective date of the merger against the payroll calendar, since a mismatch can force an awkward split period.
Before choosing this option, ask your payroll provider and tax advisor which pay periods are workable for each entity and confirm the timing from your own payroll calendar.
A mid-period cutover moves employees to the new platform part way through a pay period, and the pay for that period is split between the two systems. Earnings, overtime, leave accruals and deductions before the cutover date come from the old system, and those after come from the new one. This keeps the cutover date tied to the business need, but every pro-rated item must be calculated consistently in both systems.
- Pro-ration rules: Document how salary, allowances, bonuses, overtime and unpaid leave are split by day, hour or working-day basis, and confirm that both systems apply the same rule.
- Cutover ledger: Record the exact cutover date and time per employee group, and lock the old system for changes after that point.
- Sign-off: The payroll owner approves the pro-ration method, and the legal or HR lead confirms that the split complies with the employment terms and local rules.
- Failure mode: Inconsistent proration produces small underpayments or overpayments that are hard to explain to employees, and an employee who appears in both systems for the same days may be paid twice.
- Reporting: Tax and social reporting may need to show two sources for one period, so confirm how the filings will be produced.
Ask for a worked example of the pro-ration calculation from your payroll provider, labeled as illustrative, before agreeing to this option.
A phased cutover moves one legal entity, business unit or country at a time, and the legacy and consolidated systems run side by side until the last group is migrated. This suits merged groups with different payroll regimes, works councils or local providers, because each group can be validated before the next one moves. The cost is a longer period in which two payroll systems and two sets of rules must be maintained.
- Group order: Start with the population that has the simplest payroll rules and the most reliable data, and leave complex jurisdictions for later waves.
- Intercompany and shared data: Cross-entity payments, shared employees, group reporting and inter-entity recharges must work while the two systems coexist.
- Sign-off: Each wave needs its own approval from the local payroll owner, the entity finance lead and, where applicable, the employee representatives or works council.
- Failure mode: An employee moved between entities mid-year can end up with year-end statements split across systems, and an unclear ownership map can leave a group paid by the wrong system.
- Access and audit: Keep role-based access aligned with each wave so that staff who no longer own a group cannot change its payroll.
Confirm the wave plan, the coexistence period and the owner for each group with your advisors before committing to a sequence, since the time each wave takes depends on your own payroll calendar and local requirements.
What auditors and regulators will ask to see after the merger
This table lists the evidence an internal auditor, external assessor or data protection authority is likely to request once two workforces sit on one self-hosted HR platform. Each row names the artefact and the component or team that produces it, so the programme can assign owners before cutover. Treat the list as a starting point and confirm the exact requests with your auditors and legal counsel.
| Evidence | What it shows | Produced by |
|---|---|---|
| Approved mapping specifications | How each legacy field, code and leave type maps to the target HR data model, signed off by HR and finance owners | Migration team with HR data owners, stored in the change repository |
| Reconciliation reports | Headcount, leave balances and pay totals matched between legacy and target systems at each load and at cutover | Data Import logs and reconciliation scripts run by the migration team, reviewed by payroll |
| Change records for migration scripts | Versioned approvals for import templates, transformation code and any Server Script changes, including who enabled server_script_enabled and when | Source control, change tickets and the Frappe Server Script configuration history |
| Access logs for migration accounts | Which service and staff accounts loaded or altered employee records, with time stamps and privileged activity | Frappe activity logs, identity provider logs and the platform owner's audit trail |
| Notice and consent records | Evidence that employees received the notice of the change and, where consent applies, when and how they agreed | HR communications team and the HR case or document system, linked to each employee record |
| Register of processing and processor instructions | The updated record of processing for the combined workforce, and documented instructions for any processor or support provider with access | Data protection office, with input from the platform implementation partner |
| Archived legacy system and retrieval tests | A read-only copy of the old HR and payroll data, with dated tests showing that individual records and payslips can be retrieved | Infrastructure team for storage, HR operations for retrieval tests, reviewed against the retention schedule |
Keeping the old HR system for records retention
The legacy HR system is usually kept for a defined period because the merged company still has to produce old employment and payroll records, even after the workforce has moved. Decommissioning it on cutover day is the higher-risk choice, since a missing leaver file, an old pay statement or a payroll correction can surface years later in a tax query, wage claim or audit. Before deciding how long the old system stays, the reader should list every record family that must remain retrievable: personnel files, payroll registers, tax withholding records, leave history, and benefit enrollment data. Retention periods for each family must be confirmed with employment counsel and the company's tax advisers, because they depend on the jurisdictions where people were employed and on the rules that apply to the acquired entity.
Three options cover most cases. A read-only instance keeps the legacy application running with the login, data and reports intact, which preserves the audit trail but keeps a full stack alive, with its own patching, backups and identity integration. An exported archive in a documented format moves the records into files such as CSV with a data dictionary, signed manifests and checksums, which is cheaper to hold but only as useful as the documentation that explains it. A retained database copy keeps the native database in its original schema, which is accurate for the original application but depends on that application version being restorable. Some organizations combine them, keeping a read-only instance for the first audit window and moving older records into an archive. Test each option by pulling one leaver's full history and one year of payroll registers, timing the retrieval and checking that the output matches what was on the original screen.
The SEC's Rule 17a-4(b) under the Exchange Act sets a retention reference that some reviewers use as a benchmark, requiring broker-dealers to preserve certain records for at least three years, with the first two in an easily accessible place. It applies only to broker-dealers, so it is a reference point and not a universal rule for HR or payroll records. Treat it as a question to put to counsel rather than as the period for the merged company. The practical controls matter more than the number: keep the archive's access restricted to named roles, log every retrieval, keep a copy of the legacy application's version and configuration, and assign an owner who will still be in the role when the retention period ends.
Questions buyers ask before consolidating HR after an acquisition
How long does it take to consolidate two workforces onto one HR platform?
The duration depends on how many employee records, pay rules, leave policies and countries sit on each side, and on how many payroll cycles must run in parallel before the old system is retired. No single timeline applies across mergers, so ask any partner to break the plan into discovery, data mapping, build, test payroll runs, cutover and decommissioning, with each phase tied to a written scope. The largest time drivers are usually the number of payroll rule sets to reconcile, the quality of the target's source data, and whether the acquirer needs a single chart of leave types before close. Ask for the assumptions behind any date, including how many test cycles are planned and who signs off each one.
What does an HR consolidation cost, and what is one-time versus recurring?
The cost has several components: edition or licence fees where payroll or advanced modules are paid, hosting, localization and payroll setup, data migration, integrations, support, and internal HR and IT time. One-time costs include mapping, migration, testing and cutover. Recurring costs include hosting, subscriptions, support retainers and upgrades. For Frappe-based systems, the ERPNext pricing page states that self-hosting ERPNext is free, that Frappe Cloud shared site hosting starts at 5 US dollars per month, and that Frappe Cloud servers start at 20 US dollars per month for shared instances and 125 US dollars per month for dedicated servers. Those are hosting list prices, not the cost of a consolidation. Ask for a quote that separates each component and states who pays for it.
What work does the HR and IT team need to provide during consolidation?
HR owns the decisions that the data encodes: which leave policies survive, how contract terms carry over, which pay codes map to which, and who approves exceptions. IT owns the environment, identity integration, access roles, backups and the change control around each cutover. Both teams must agree who signs off each data load and each payroll test run. Expect HR to spend most of its time on reconciliation of balances and contract terms, and IT to spend most of its time on environments, single sign-on and access reviews. Confirm the named owners, their hours during payroll freezes and the approval steps before the work starts.
Can our in-house team run an HR consolidation without an outside partner?
A capable in-house team can run a consolidation if it has people who know both payroll rule sets, has the platform skills to configure and test the target system, and has time that does not compete with the live payroll calendar. Most gaps appear in three places: payroll localization across countries, data migration from the legacy HRIS, and the cutover plan with rollback. A partner can fill those gaps on a fixed-scope basis, while the internal team keeps ownership of policy decisions. Compare the internal capacity against the list of tasks in writing, and ask any partner to name the skills it brings and the work it will leave with your staff.
Do employees need to consent to or be notified about moving their HR data?
Often yes, and the answer depends on the jurisdictions involved, the lawful basis for processing, and any works council or collective agreement that applies. In the EU, GDPR requires that processing follows documented instructions and that records of processing are kept, so the acquirer's legal team should confirm the lawful basis for each data category before migration. Employees may also need a clear notice about what moves, where it is hosted and who can access it. Local employment law can require consultation before changes to working conditions. Ask counsel to sign off the notice wording and the consultation steps, and build those steps into the schedule before any data load.
Can the acquirer see target employee data before the deal closes?
Access before close is restricted by the target's data protection obligations, competition and confidentiality agreements, and any transfer rules that apply. Where EU personal data is involved, EDPB Guidelines 05/2021 treat remote access from a third country, including for support or administration, as a transfer that needs a Chapter V transfer tool, so a non-EEA acquirer's staff cannot simply log into the target's systems. Usually the acquirer works from a sanitized or aggregated extract until closing, under a data sharing agreement reviewed by counsel. Confirm with the legal team which data can be shared, in what form, and where it may be processed.
What happens if payroll fails in the first run on the new system?
A failed first run should be handled through a tested fallback, not by improvising during the pay date. The plan should include parallel payroll runs before cutover, reconciliation of gross to net totals against the legacy system, a defined go or no-go decision with named approvers, and a documented rollback path that keeps the legacy system able to pay employees for the affected cycle. Confirm with the partner how many test cycles are planned, who can authorize a fallback, and how corrected payments and tax filings are handled. Keep the old system and its data available for record retention, because payroll and tax records may need to be produced after cutover.
How should the legacy HR system be kept for records retention?
The legacy system or a read-only archive should remain available for the retention period that applies to each record type, which depends on country, employment law and tax rules. Without a supplied retention schedule for your jurisdiction, ask counsel to confirm the periods before you decommission anything. Retain the export format, the data dictionary, the audit logs and the backup set needed to read the records. Test that an archived record can be retrieved and produced on request before the old system is switched off, and record who owns the archive after the consolidation project ends.
What to ask an implementation partner before signing
Start with payroll localization, because it decides whether a consolidated platform can run payroll on day one. Ask the partner to name, for each country in the combined workforce, which payroll rules, tax tables and statutory reports they have implemented in the HR platform and which they would build or integrate with a local provider. Ask whether they have run a parallel payroll for a live cycle and how they compared net pay between the old and new systems. Ask for references they can describe in general terms, not for client names, and for the edition and licensing needs behind any module they propose. For Odoo, confirm whether the required payroll and HR functions sit in the Enterprise edition, since the Community edition alone may not cover them, and ask how the partner would handle the upgrade path given Odoo's support windows. For ERPNext and Frappe HR, confirm that the chosen version is on Frappe's supported versions list and that the partner has a support arrangement that matches it.
Ask how the partner handles non-EEA access to EU employee data. Remote access from a third country, including support or administration by an acquirer's staff, counts as a transfer under EDPB Guidelines 05/2021, so the partner should show which transfer tool applies, who holds administrator credentials, and how access is logged. Ask them to walk through the parallel run and rollback plan: how long both systems stay live, which leave balances and contract records are frozen at cutover, how a failed payroll cycle is reversed, and who can approve a return to the legacy system. Ask who signs off on each reconciliation (headcount, leave balances, gross-to-net totals and employer taxes) and whether that sign-off sits with HR, finance or an external reviewer. Finally, ask for the retention archive design: which read-only copy of the old system is kept, where it is hosted, how long it is held against the record periods in your jurisdictions, and how it is restored for an audit.
Request a written scope with deliverables, milestones and acceptance criteria before any work starts. Most DeployOpen engagements are fixed-scope, so the document should list each country, each data source, each migration batch and each reconciliation report, along with the sign-off owner for each. Ask the partner to state which items are excluded, such as local payroll filings the partner does not prepare, and what changes to the scope would require a new quote. Ask for the handover package, including runbooks for payroll cycles, backup and restore tests for the archive, and the support terms for the first payroll runs after go-live. Confirm these details in writing with the partner and with your own legal and works council advisers, because the answers determine which records must stay accessible and for how long.
How DeployOpen scopes and delivers an HR consolidation
The sequence turns two workforces, two sets of records and two payroll calendars into one self-hosted HR platform that runs inside the client's infrastructure, with written scope, tested migration, documented controls and a defined cutover.
Agree the written scope and boundaries
DeployOpen and the client agree a fixed scope in writing before work starts. The document names the entities and countries in scope, the chosen platform and edition, the records to migrate, the payroll runs affected, the hosting location, and who holds administrator access. It also lists what is excluded, such as legacy system decommissioning or local payroll provider changes. The output is a signed scope, deliverables and a timeline that the client can hold DeployOpen to.
Map employee master data across both workforces
Working with HR and the integration team, DeployOpen builds a field-by-field map from each legacy HRIS into one data model. Duplicate employees, conflicting job codes, legal entity assignments and manager hierarchies are identified and resolved by data owners, not by the implementation team alone. The output is an approved mapping workbook and a list of open data decisions, each with a named owner.
Design the platform and identity integration
DeployOpen plans the self-hosted deployment inside the client's cloud account, data center or private network, including environments for build, test and production. It also designs role-based access for HR, managers and payroll staff, and how single sign-on and provisioning will connect to the identity platform. The output is an architecture record and an access matrix reviewed by the client's security and HR owners.
Build conversions and test migration runs
The team configures leave types, balances, contract templates and approval flows, then loads records into a test environment. Leave balances and contract terms are reconciled against source extracts for each population. Migration runs are repeated until error counts and reconciliation differences are explained and accepted in writing. The output is a migration test report and a signed sign-off list for each data domain.
Harden the platform and document controls
DeployOpen applies hardening to the servers, database, backups, administrator accounts and integrations, and reviews the configuration against the client's security baseline. Change management, access review and logging procedures are written so that operators can follow them after handover. The output is a hardening record, control documentation and evidence files that the client's auditors or assessors can request. DeployOpen prepares this evidence but does not issue audit reports or certifications.
Rehearse payroll cutover and communicate to staff
The cutover plan sets the payroll freeze, final legacy extracts, the parallel run where the client runs both payrolls, and the go or no-go criteria. Employee notices and consent steps are coordinated with HR and legal counsel, since they vary by jurisdiction. The team rehearses the cutover at least once against a production-like copy. The output is a cutover runbook and a rehearsal record with agreed rollback points.
Cut over and archive the legacy system
On the agreed date, DeployOpen executes the final data load, switches access and integrations, and monitors the first payroll and leave cycles with the client's team. The legacy system is set to read-only and retained for records retention, with a documented index of what it holds and who can retrieve it. The output is a cutover close-out report and an archive record that states how each retained record type can be produced.
Hand over and offer retainer support
After cutover, DeployOpen transfers runbooks, administration guides and training materials to the client's operators. Ongoing support, upgrades and testing can be placed under a separate retainer, scoped in writing, if the client wants continued help. The output is a handover pack and a signed acceptance, with any retainer scope agreed separately from the consolidation project.
