Live in 4–6 weeks. Watched forever.

Four steps, four to six weeks, and one gate nothing ships past: a parallel run against a real payroll cycle, judged by your team. Somewhere in those weeks your payroll still runs — this page is for the person who owns that. What happens each week, what each week asks of whom, why the timeline is honest, what happens if the outputs don't match, and what changes on day 31 — written to double as the project plan: forward it, and the person who approves the budget and the person who creates the service account are reading the same document you are.

Four-step implementation timeline from discovery to go-live

Handing this to whoever has to approve or staff it? The plan, on one screen.

Timeline: 4–6 weeks from a kickoff scheduled at signing, for a typical two-system pair — then 30 days of hypercare
Week 1 — Discovery & data audit: both systems inventoried, data quality audited, scope and direction agreed
Week 2 — Field mapping & rules: every in-scope field named in a mapping document — versioned, signed by you, yours to keep
Weeks 3–5 — Build & parallel run: the integration runs beside a real payroll cycle; your payroll team checks the two outputs against each other, record for record
Week 6+ — Go-live & hypercare: cutover, then a 30-day hypercare window of heightened monitoring
Your side: a scoped service account you create · one mapping workshop · a UAT contact who runs the parallel-run comparison · two signatures — the mapping document and the cutover — the IT side is hours, not weeks
The gate: nothing writes to your payroll system until the parallel-run outputs match — and the cutover signature is yours, not ours
The money: setup billed 50% at signing, 50% at go-live — the go-live half is never invoiced if the parallel run can't be made to match · the monthly fee and your 12-month term start at go-live → Pricing
From day one: your data is handled to production rules from week-1 discovery → Security
After hypercare: nothing else changes — scheduled syncs, the dashboard, the 99.5% SLA that's been live since go-live → SLA & Support

OmniSync HR · How It Works · as of 2026-07-11

While we build, nothing about your payroll changes ¶

The quiet fear under every integration project: that the project itself breaks the thing it was bought to protect. So the standing rule comes before the timeline. During implementation, the platform reads — it writes nothing to your payroll system. Not a test record, not a draft entry: production writes begin at cutover, after the parallel run matches and you've signed. Your team keeps running payroll exactly as it runs today, through every cutoff of the build — the integration runs beside that process, not inside it.

And the data it reads is treated like the production data it is: the same encryption, the same credential-scoping rules, and the same 90-day retention apply from the first day of discovery — handled to production rules before anything is live.

What we hold, on the Security page →

One more thing we take from the first call: your payroll calendar. The kickoff, the workshop, the mapping review, and cutover are scheduled around your cutoffs, not on top of them — the project that ends the cutoff scramble shouldn't cause one.

WK 1
Week 1 — Discovery & data audit ¶

What happens

we inventory both systems — entities, code tables, pay elements, which of the four data domains apply to you and in which direction — and audit the data the sync will carry. The audit isn't a formality before the real work; it is the real work of week 1, because a sync is only as good as its source data, and the problems that could stall the parallel-run comparison are cheapest to find here.

Your part

the scoped service account — minted in your own system, by you, read-only through discovery and narrowed to exactly your signed mapping scope at the week-2 sign-off — and the mapping workshop: one session, with the people who know how payroll actually runs in the room. It's the only workshop the engagement asks of you, and it feeds the week-2 mapping document.

What exists at the end

an agreed scope — which domains, which direction, your sync cadence confirmed against your payroll calendar — and the audit's findings in writing, each marked with whose fix it is.

What your payroll team feels at cutoff

nothing. The cycle runs exactly as it always has.
WK 2
Week 2 — Field mapping & rules ¶

What happens

every in-scope field, code table, and transformation is written down in your mapping document — versioned, signed off, yours to keep. Nothing outside it will ever move, and our credential can reach nothing the document doesn't name.

Your part

review the document with the people who sat in the workshop — then sign it.

What the signature means

control, not a trap. Your signature fixes what may move — and integration access is held to the signed version, nothing more. It doesn't move the fault line: if a record ever goes wrong because of the mapping logic or the platform, that fix is ours — the same rule the quarantine queue runs on.
When a record is wrong →
And if a mapping is wrong anyway, the parallel run catches it before production ever sees it — what happens then. The fix ships as a new signed version, because a mapping change without your signature doesn't ship at all.

What exists at the end

the signed mapping document. The build builds to it, and only to it.

Weeks 3–5 — Build & parallel run: the test you preside over ¶

We build to the signed document. Then comes the step that makes the go-live date honest — and it's worth stripping the acronym off "parallel-run UAT," because to most payroll teams UAT means unpaid QA stacked on cutoff week. Here's what it actually is.

Your team runs a real payroll cycle the way it runs every cycle — same cutoff, same process, nothing staged. Beside it, the integration produces its version of the same movements: the hires, the terminations, the comp changes it picked up from your HRIS. Nothing writes to your payroll system. Then you put the two outputs side by side — we prepare the comparison, differences flagged, so your team reviews rather than reconstructs.

You've done this comparison before — it's the 9 p.m. spreadsheet job this platform was bought to end. The difference is what a mismatch means: found here, it's a work item — traced to whichever side owns it, fixed there, and shown to you again. Found after a careless go-live, it would have been a payslip. That's why the run happens against a real cycle, before anything writes: any vendor can demo a sync on clean data, and your payroll isn't a demo — so the test isn't either.

Your part: the comparing. Your UAT contact holds our output against the payroll your team just ran and says "same" or "not the same" — a payroll you already know, checked against ours. And "match" isn't a vibe: your contract states exactly what it means, before anyone signs.

What exists at the end: proof — or a list of mismatches, and here's what happens then. Either way, go-live is a state your numbers reach, not a date we announce.

What if the outputs don't match? ¶

At first, sometimes they won't — a code table nobody documented, a mapping gap, a record the week-1 audit flagged. That's what the rehearsal is for: each mismatch is traced to its cause and fixed where the fault lives — mapping and platform gaps on our side, source-data problems named for you to fix in the system that owns the record — and the comparison runs again. Go-live waits on the match, however the calendar feels about that.

And if it can't be made to match at all? Then nothing goes live — and the price already knew it might not. The setup fee is invoiced half at signing, half at go-live, and the go-live half is never invoiced if the parallel run can't be made to match. The monthly fee and your 12-month term haven't started either — both begin at go-live, so the months before you're live are months you're never billed for.

When you pay, on the Pricing page →

We wrote the failure case into the invoice because we don't expect to meet it — and because expecting you to simply believe that is exactly what the invoice is for. However long the road to a matched run takes, the clock that costs you money isn't the one running.

Go-live, hypercare, and day 31 ¶

Cutover. By go-live, the integration's output has already been verified against a real payroll cycle — by your team. Cutover is the moment production writes begin — the same sync that just passed your parallel run, now allowed to write — after the outputs match and you've signed, never before. Not a leap: a repeat.
Days 1–30: hypercare. For 30 days after cutover, monitoring runs heightened — on either tier — because your first live cutoff (often two, on a PH semi-monthly calendar) lands inside this window, and it gets more scrutiny than an ordinary month. Hypercare sits on top of the SLA, not in place of it: the 99.5% commitment, the same-business-day re-run, and the service credits are all live from go-live — the same day your term starts. Your dashboard and reconciliation reports run from cutover day, so your first live cutoff sign-off is a read-through, not a vigil.
Day 31 is the point. Most implementation stories end at go-live, because the implementer leaves at go-live. Ours can't: the engineers who built your integration are the ones operating it at the next cutoff, and the one after that — there was never a handoff to hand off to. When hypercare ends, the scaffolding comes down and nothing else changes, because nothing else was temporary: scheduled syncs at the cadence you set, the dashboard already answering the question you'll bring to it every cutoff, and the SLA measured monthly, with service credits attached.

Read the SLA → · A month with the sync running →

And your old process? Nothing about the platform requires you to stop checking. Retire the spreadsheet when the reports have earned it.

The gate is the guarantee. The call is where the road starts.

A scoping call sizes the plan above to the systems and payroll calendar you actually run.

Book a scoping call

The plan above becomes your fixed quote.

Why 4–6 weeks — and why not two ¶

The two questions this number gets, in order.

Why it isn't two. Ask anyone who has shipped a Workday payroll integration: the standard guidance for testing one runs a minimum of about six weeks end to end — when it includes what ours includes, a parallel run against a real payroll cycle. We quote under that minimum only because everything compressible is spent before the build — the second answer below — and only when your payroll calendar cooperates; six is the honest middle of our range. A vendor quoting two weeks is quoting a build without the rehearsal, and a first live cutoff that doubles as the test. The weeks between four and six aren't slack — they're the part that makes go-live a repeat of something that already worked, not a first attempt.

Why it isn't twenty. Because the compression happens before the build, never after the proof. The scope is fixed on paper you sign — every field named in the mapping document, so the build has no discovery left in it. For the pairs these weeks are quoted against, the connections are the vendors' supported APIs — a system that needs screen-based or direct-database connectivity is custom scope, and its quote carries its own timeline. And the same engineers run discovery through parallel run. The weeks that balloon integration projects — discovery that never converges, scope found mid-build — are spent here in weeks 1 and 2, on purpose.

What sets the count inside the range isn't our optimism — it's your payroll calendar. The parallel run needs a real cutoff to run beside, and your calendar decides when the next one lands. A cycle that falls early in the build window makes it four weeks; one that doesn't makes it six.

And if the weeks slip? The answer is an invoice, not a promise — the failure case is priced in.

What implementation asks of your team — itemized ¶

Forwarded here by someone who wants your sign-off? Every integration vendor promises a light lift. So instead of the adjective, here's the itemized version:

A scoped service account — week 1, created by you, in your own tenant. In Workday, an ISU. The scope is yours to set — read-only through discovery, narrowed at the week-2 sign-off to exactly what your signed mapping document covers — and you can switch it off without asking us. How it connects →
One mapping workshop — week 1. The people who know both systems, in one session, naming what maps to what. It feeds the week-2 mapping document — versioned, signed, yours to keep.
A UAT contact — weeks 3–5. Someone who can put our output next to your real payroll run and say "same" or "not the same." That comparison is the go-live gate, so this is the seat with the power.
Two signatures. The mapping document in week 2; the cutover once the outputs match.

That's the entire ask — and if a fifth item ever appears mid-implementation, it's our scoping failure to absorb, never your change order. What's deliberately not on it: no sandbox or test tenant to stand up, no middleware to license or patch, no code to own, no new on-call rota. The building, hosting, watching, and maintaining are the things you're paying us for.

The IT side of this is hours, not weeks. And one asymmetry printed rather than discovered: the biggest single task on your side is the parallel-run comparison, and it belongs to payroll, not IT — checking a payroll your team already knows against ours, row by row, one more time. For the last time by hand: after go-live, the check is the reconciliation report.

Three variations on the plan ¶

Running Premium? Same four steps, same gate. Your custom business logic is designed and built as part of the same implementation — drafted in the mapping weeks, proven in the same parallel run, never bolted on after — and it's named in your quote before you sign.

A pair we haven't built before — or a system with no API? A first-of-its-kind connector is scoped as exactly that: the same four steps, the same gate, with the timeline stated in your quote. Vendor-API connectors built first for your engagement carry the full 99.5% SLA from go-live; a screen-based or direct-database connection is custom scope, with a connection-specific SLA defined in the quote.

Not on the list? →

Adding a second pair? Discovery and infrastructure are already done — that's why setup is 30% off — but a pair is never half a project: each one gets its own mapping document, its own parallel run, and its own go-live. Starting two at once? They run staggered by design — so each build and each parallel run gets full attention — and one scoping call covers them both.

Adding integrations →

Implementation questions, answered the way the project owner asks them ¶

Do we have to run payroll differently while you build?

No — your process runs unchanged through every cutoff of the build, and the platform writes nothing to your payroll system until cutover.

While we build, nothing changes →

When does week 1 start after we sign?

At a kickoff we schedule with you at signing, set against your payroll calendar. The 4–6 weeks run from that kickoff — why the calendar drives the plan.

How do we know this will work on our setup?

You verify it: the parallel run proves the integration against your own payroll cycle before anything goes live — and if it can't be made to match, the second half of the setup fee never gets billed.

What happens then →

When do we start paying?

Half the setup fee at signing — that's all until go-live, when the second half is invoiced and the monthly fee and your 12-month term begin.

When you pay →

What if it takes longer than six weeks?

The range holds for a typical two-system pair — a longer build is printed in your quote, not discovered in week five. Either way, the meter isn't running — the failure case is priced in.

What does this actually take from our team?

A scoped service account you create, one mapping workshop, a UAT contact for the parallel-run comparison, and two signatures.

The itemized ask →

Do you need a sandbox or test tenant?

No — the platform reads your production systems through their vendor APIs, with writes disabled until the signed cutover, so there's nothing to provision or refresh. The parallel run exercises the same build that goes live.

While we build →

A Workday release is scheduled during our build window — does that reset anything?

No — vendor releases are ours to absorb during the build exactly as they are after go-live, and one that lands during the parallel run is re-verified by it.

Change management, on the Product page →

Is our employee data safe while you build?

Yes — real records are handled to production rules from the first day of discovery.

The standing rule → · The master answer, on the Security page →

Who decides when it goes live?

Your team does: nothing writes to production until you've compared the parallel-run outputs and signed the cutover. Go-live waits on your verdict, not our calendar.

The test you preside over →

Can we implement two pairs at once?

Yes — the second pair gets the same 30% setup discount whether it starts alongside the first or a year later, and the builds run staggered by design, each with its own parallel run and go-live.

Three variations on the plan →

Does adding the Compliance Pack change the timeline?

No — it's configured at onboarding, on the domains you're already syncing: no separate data feed to stand up, no step added to the four above.

The Compliance Pack →

You've read the plan. The call is week zero.

Everything on this page is the standard shape of an engagement — what the scoping call adds is your half of it: which systems, which domains are in scope, and your payroll calendar. You get a fixed quote within a week, whether or not you buy — and if your stack needs a different tool, that gets said on the call, not discovered in week three. The four steps start at a kickoff we schedule when you sign; until then, the only thing on your calendar is the call.