Planning a When I Work migration

Name the authoritative system and its business owner for each record family before extraction. Start by reproducing this case: a schedule change that was entered in one system but communicated through a separate channel. Do not migrate a spreadsheet or export until the owner confirms it is the current source.

Prioritize the records required for inventorying worker, location, role, schedule and time data before mapping it to a new operating model. Separate active operating records from closed history, duplicate entries and fields that are not needed after cutover.

Use an authorized administrator export or vendor-supported method and preserve the original files unchanged. For a source product, confirm export permissions, date windows, archived-user behavior and included fields from its current help documentation.

Create a source-to-target dictionary for each field used in inventorying worker, location, role, schedule and time data before mapping it to a new operating model. Include source name, destination meaning, type, required/optional status, transformation rule, owner and test example. Do not assume a same-named field has the same meaning.

Choose an approved stable identifier, define duplicate handling and have HR/payroll owners resolve conflicts before loading. In particular, investigate the identity mismatch in this scenario: a schedule change that was entered in one system but communicated through a separate channel. Never merge records using name alone.

Create an approved crosswalk from source locations, departments, jobs or cost codes to the target's intended structure. Identify retired sites and ambiguous codes, then test one current and one closed location before production.

Move only history needed for continuity, reporting or an approved retention purpose. Preserve an accessible source archive for older records when direct import is not required; a schedule export is not necessarily a complete backup.

Separate scheduled shifts, raw punches, approved timesheets and later corrections. Confirm which timestamp and version is authoritative and preserve approval context if it is needed for reconciliation.

Inventory every custom field, document its meaning and usage, and classify it as map, transform, archive or retire. Ask business owners to approve transformed values; do not silently repurpose fields.

Profile null, malformed and conflicting values before a test load. Assign a named data owner to resolve required records, define an explicit exclusion list and publish rejected-row reasons rather than inventing worker or site details.

Inventory document type, owner, status, effective date and access need. Confirm authority, retention and secure transfer before moving personal documents. A file presence alone does not prove a credential is valid or a course was passed.

Limit exports, working files and test environments to named roles; remove unnecessary sensitive fields; use approved transfer and storage locations; log access; and set a deletion date for temporary copies.

Load a representative sample covering sites, worker types, active/inactive records and the identified scenario. a schedule change that was entered in one system but communicated through a separate channel. Record rejected rows and compare key fields with their source before expanding the sample.

Have supervisors and payroll owners complete a realistic worker journey from roster/readiness through attendance correction and final handoff. Sign-off should identify the exact test data, expected result, defect disposition and accountable owner.

Compare source and destination counts by record family and location, sample identity and relationship fields, and reconcile business totals such as scheduled shifts or approved hours where applicable. Explain every variance; a matching row count alone is not acceptance.

Keep the source row, rejection reason, responsible owner and resolution status in a controlled exception log. Re-run only approved corrections and compare the next load with the prior result to avoid duplicate records.

Agree a change window and last-export timestamp with system owners. Decide which changes remain in the source, which are captured in a delta file, and who reconciles changes made between test and production loads.

Choose which system is authoritative for each data type and set a finite parallel period. Compare schedule changes, attendance exceptions and payroll-ready totals; define the threshold that blocks expansion and the decision owner.

Before go-live, specify the trigger, decision maker, source-of-truth, communications, preservation of new records and steps to restore the prior operating process. Test the rollback checklist on paper; do not assume imported data can be automatically reversed.

Require approved mappings, resolved critical exceptions, access review, successful reconciliation, trained supervisors, payroll confirmation, worker communication and a signed rollback decision. Hirebase migration mechanics and any custom import work must be agreed in the engagement scope.

Record the account, export owner, selected record types, date window, filters, timezone, export timestamp and file names. Keep an untouched source copy with restricted access so later reconciliation can trace which snapshot was loaded.

Agree exclusions for duplicates, obsolete locations, test accounts, malformed identifiers and records outside the approved purpose. Store the reason and owner in the exception log; exclusion should be an explicit decision, not a silent dropped row.

Identify calculated cells, hidden columns, lookup tabs and manually entered overrides. Recompute or retain a value only when its definition and source are approved; preserve the original workbook as evidence and document the target transformation.

Choose a delta process with a clear comparison key and last-change timestamp, or schedule a final full extract inside a controlled freeze window. Reconcile inserted, updated and deactivated records before production acceptance.

Document whether dates represent creation, assignment start, approval, pay period or status change. Preserve source timezone and business date semantics, then test a shift crossing midnight and an assignment changed near the cutover boundary.

Check that each worker links to a valid site, role, supervisor and any required payroll code. Produce a report for orphaned links and resolve them with the record owner before loading dependent rows.

Include source row key, target field, rejected value, validation reason, owner, resolution, retry batch and final disposition. Do not overwrite a source value just to make a row pass validation.

Give managers a review sample covering ordinary, changed and exceptional records from their locations. Ask them to verify names/IDs, assignments, dates, status and approval history against authorized source evidence before they approve the test load.

For the first operating cycles, review unmatched identities, missing assignments, schedule changes, attendance exceptions, rejected payroll rows and support requests daily. Assign owners and stop expansion if a critical reconciliation threshold is missed.

Retain the approved source archive for the period set by the organization's records policy and applicable obligations. Before retirement, verify access, export integrity, searchability, legal holds and documented approval to delete any temporary migration copies.

Run a schedule change that was entered in one system but communicated through a separate channel from assignment through attendance review. Ask the vendor to identify the source record, configured checks, supervisor decision and final approved time. Mark any a focused scheduling and time product requirement for a separate product evaluation.

Set a canonical site ID, address, effective dates, local supervisor and payroll/job mapping for each active location. Test a transfer between two sites and decide who owns address and boundary corrections.

Keep the scheduled assignment, punch context, worker explanation, reviewer's decision and change reason together. Define a backup approver for nights, weekends or client-site work so an exception does not remain unresolved through payroll cutoff.

Agree the minimum readiness record for the role and site: identity, assignment eligibility, selected documents or passed courses, and supervisor instructions. Keep a focused scheduling and time product in the system that owns that specialist workflow.

Name who can change the assignment, how the worker and supervisor are informed, which site requirements need rechecking and how the published schedule is distinguished from the original. Use a schedule change that was entered in one system but communicated through a separate channel as an acceptance test.

Select a representative location and worker group, then include a normal shift, an assignment change, a missed punch and a manager-approved correction. Measure readiness completion, exception aging and reconciled hours before adding more sites.

Limit migration to active worker, location, assignment and readiness information required for the agreed workflow. Keep candidate history, clinical records, inventory, route planning or other specialist data in their authoritative systems unless a separate approved scope requires a transfer.

Have payroll confirm identifiers, earning codes, cutoff, approved-hours format and variance handling. Hirebase calculates wages from attendance; the payroll provider disburses funds and files. Keep customer billing, commissions or other distinct amounts outside the wage calculation unless separately confirmed.

Test the actual worker approach at entrances, adjacent tenants and common parking areas using representative devices. Choose the configured geofence with operations owners, then route ambiguous or valid edge cases for review instead of silently changing the boundary.

Set baseline and target definitions for assignment coverage, readiness, attendance exceptions, approval turnaround and payroll reconciliation. Add a domain measure tied to inventorying worker, location, role, schedule and time data before mapping it to a new operating model; do not report a service or customer outcome that the workforce record cannot establish.