HR software implementation

After selecting an HR system, implement it by assigning owners, preparing records, testing configured workflows and planning the move to live use. Set a decision point for each stage. A successful import or active login does not prove the whole HR process works.

Agree on ownership and scope

Name an implementation owner and the people authorised to decide HR process, payroll, data, security and employee communication questions. List the systems that will remain in use.

Where systems share a field or request, identify the authoritative record and how an approved change reaches the others.

Choose a few journeys to prove: a starter, a change during employment, a request and an employee leaving. Add a frequent exception from your organisation.

For each, record the trigger, decision-maker, final record, downstream recipient and correction route.

Prepare records and access

Map each field that will move: its source, meaning, target, owner and treatment of blank or conflicting values.

Decide how retained history will be retrieved if it does not appear in the new profile. Compare trial imports with approved source records. Counts can expose missing rows; individual checks can expose wrong dates or values.

Consult Fair Work Ombudsman record-keeping guidance. Have the responsible specialist identify which systems will retain and produce the applicable records before retiring an old interface.

Check employee, manager, HR, payroll and administrator access, including reports, exports and notifications. Have the privacy owner review the OAIC’s employee records exemption guidance and assess how privacy obligations apply to the employer’s and any supplier’s handling of employee information.

Have the privacy owner assess the actual supplier and data flows. For cloud software, confirm the supplier’s and employer’s respective access, configuration, backup and incident tasks for the service purchased.

Old vs New System: Data and Access Handling

Prove the configured workflows

Write expected results before testing. Use synthetic or suitably protected records and accounts for the relevant roles.

Follow each request from submission through approval, rejection or correction to the resulting record and any receiving system. Record what happened at each boundary.

Choose pilot participants whose roles and work patterns reflect launch use. Give them tasks they would normally perform and a way to report confusion or failure.

Classify each issue as a launch blocker, an owned manual workaround or later work. A trial limited to HR administrators cannot establish that employee and manager journeys work.

Where a workflow affects pay, have a qualified payroll reviewer establish the expected treatment and inspect the receiving result. Transfer to payroll alone does not establish correct pay.

Treat pilot acceptance and live improvement as separate stage gates. Use pilot results to decide readiness, then assign an owner to review issues arising in live use.

Make the cutover decision

Agree when updates stop in the old system, when the final extract occurs, who may enter changes during transition and how late changes will be reconciled. Name the conditions that would delay launch and the person authorised to decide. Keep a route to retrieve old records while the new process settles.

The launch decision should state which journeys passed, which remain untested, what record and access checks found, whether integrations work, and who owns open issues and employee help. Keep a critical approval or pay-related handoff open until its result has been checked.

Keep migration acceptance and legacy retirement as separate decisions. Before approving retirement, confirm that records remain retrievable and that operational dependencies on the old system have been addressed.

Transfer to ongoing ownership

Tell employees where to get help and report a wrong record. Give each material issue an owner and next update.

Transfer permissions, records, integrations, help content and unresolved defects to the people who will maintain them. Close the project when ordinary users can complete the agreed work and the operational team can handle exceptions.