Why Ashby's integration is a game changer
I’ve spent a large part of my career caring about a thing almost nobody else in a company wants to think about - integrations. The unglamorous connections that move data between your different systems, that everyone ignores right up until the Monday morning they break and suddenly somebody’s new hire doesn’t exist in the HRIS. If you have ever lived that Monday, this one is for you.
TLDR; Ashby's native integration is the best thing about it IMO, and it has also changed how I think about deploying and running an HR tech deployment in general. I will keep the watch points in at the end, because there are always trade-offs and I would not be a great advisor if I did not highlight these too!
What "native" actually means, and why it matters
Most ATS-to-HRIS integrations you have used are not really integrations in the way you imagine, they’re reports - at least for master data; transactional data often moves via triggers, messages or files, though the brittleness is the same. A scheduled job runs a report, that report gets pushed somewhere, and something on the other end tries to make sense of it and sometimes breaks. Greenhouse's report-based connector “HRIS link” was exactly this, so was the old H-Link style of moving data around, and so is a lot of what happens inside Workday Studio.
The problem with a report-based integration is that it is brittle in a very specific and infuriating way. As soon as one value does not match, or an organisation or other field goes inactive, it can block the entire flow. You end up doing constant, low-grade maintenance to keep the thing alive, filtering out inactive records, chasing mismatches, babysitting an “automation” that should just well, work. The amount of business this generates for consultants and contractors globally is crazy - a whole ecosystem, and an annual overhead that was not factored in when you first crunched the numbers on Greenhouse, Lever or SmartRecruiters. (The Workday folks here will say - HEY! This is why you need Workday Recruiting, but the reality is that the trade-offs are still significant and this is one of Workday’s least popular modules - admitted here by a former Workday Recruiting Product Partner Lead!).
Ashby's integration is not a report, it’s natively built and, more importantly, natively supported by Ashby. If a record goes inactive, the flow may still stall - but resolving it is now a collaboration between you and Ashby, often self-serve in Ashby's own UI, rather than a ticket to an third party integrations consultant. Because Ashby owns the integration end to end, the responsibility for it working sits with them, not with you! The onus for a failure moves off the customer and onto the vendor. In more than a decade around this stuff, that is one of the more meaningful shifts I have seen.
The practical effect is close to zero ongoing maintenance for the integration. You are only dependent on Ashby when you actively want to change something, such as adding a new custom field or mapping a new attribute. The rest of the time, it just runs nicely.
The knock-on effects are bigger than the feature
Here is where it gets genuinely interesting, because a good integration architecture changes the shape of the whole project.
You may not need an integration specialist at all
On a traditional Greenhouse or Workday programme, a dedicated integration person is often a non-negotiable line on the plan. On an Ashby project, the heavy lifting sits on Ashby's side. That is a real reduction in cost, complexity and key-person risk on a deployment. The risk shifts rather than disappears - it becomes Ashby's capacity and SLA response rather than your contractor's availability and it lets you point your budget and your best people at the work that actually differentiates the outcome. The person responsible for the integration operating can be a RecOps expert, not a technical expert. This is a win. There is an awesome interview here with Ligita Kondrataviciute , Senior Candidate Experience Manager at Deliveroo where she describes the practical impact of this.
It exposes your mess and creates an environment where fixing it is the only option
Because the integration is clean and reliable, it stops absorbing the chaos that a fragile report-based connection used to hide. Suddenly your inconsistent job titles, your unloved job req processes and your years of accumulated data debt are visible in real-time downstream in Workday or whichever HRIS you are running. It's tempting to blame the integration for this, but don't - the integration is doing its job. What it is really giving you is an honest audit of the processes you have been carrying, and a reason to finally fix them.
The deployment style this unlocks is the real game changer
Here is the part that made me a convert, and it flows directly from the native architecture. The traditional way to migrate an ATS is a big-bang cutover. You spend weeks cleaning and exporting your data, you configure the new system standalone, and then one nervous cutover period later you brace yourself for impact. Everyone who has done it knows the feeling. Sat in a "war room" waiting for issues to flood in.
Ashby lets you run it almost backwards, and it is far better for it. You can switch the API connection to your existing Greenhouse or Lever instance on more or less day one, it pulls your live data across, and you build and refine your processes on top of that real dataset from the very start. Recruiters keep working in the old system through a parallel-run window while you shape the new one around what is actually there, and you only cut over once it genuinely fits.
I'll be honest that this feels deeply counterintuitive the first time (!). Every instinct built up over years of deployments screams that you should design the processes and clean the data first and migrate last, and here you are pointing the new system at all your existing mess on the opening day. It is a little scary, but it actually works, and it works better, because you are designing against reality instead of against a tidy sample that falls apart on go-live. Problems surface in week one when they are cheap and low-impact to fix, not on cutover weekend when they are not.
This is one of the key accelerators for Ashby deployments - custom connectors that pull everything over, migrations measured in days rather than months, in some cases roughly 48 hours from handing over an API key to having the data imported. Ramp, HackerOne and Brightline all describe go-lives that were fast and, tellingly, quiet, with Brightline reporting a month from signing to fully migrated and live. A silent go-live is the highest compliment you can pay a migration!
One important caveat - because that API pulls across everything, the good, the bad and the messy, the approach rewards you for using the parallel-run window to standardise and tidy as you build, rather than faithfully rebuilding your old chaos in a new home. The method forces you to make difficult decisions and doesn’t offer a lot of workarounds. I think this exact pattern, connect early and build on live data, is coming to HRIS deployments next, and it will reset expectations for how fast a good migration should feel. Let's see how fast these can get next!
The watch points
The trade-off for all this is dependence. Because Ashby owns the integration, you rely on them for custom fields and certain configuration rather than doing it yourself whenever you like. If you are a back-end purist who wants total control and have a huge organisation with massive complexity, this will feel like giving something up. My honest view is that it is a trade worth making, because in practice most companies create new custom fields rarely, a handful of times over several years, not every quarter. You are exchanging a small amount of day-to-day flexibility for a large amount of reliability. That is a good deal for almost everyone.
The one thing you cannot be lazy about is the setup. You choose which fields to map and what to transfer, and Ashby does the mapping, so getting that design right at the start genuinely matters. You have less room to rework it cheaply later than you would with a fully self-managed connector. This is not a reason to hesitate, it's a reason to prepare properly, map deliberately, and get your process design settled before you build. Solid preparation is what turns this from a risk into the quiet superpower it should be.
That preparation, the mapping, the process design, the deciding what good actually looks like before you switch anything on, is most of the real work in a migration, and it is where we spend our time at Wave1. The integration will reward you for doing it well and expose you if you skip it!
Where we come in
At Wave1 , we think beyond single platform switches and help bring to life your whole RecOps transformation via flexible deployment, integration and automation services.
If you are weighing up a move to Ashby and need help to navigate decision making, or are about to deploy and lacking the internal resources to do it properly, let us know!