From nights that ran past midnight to releases done in minutes
Paylocity runs a single production org supporting 4,000 Salesforce end users, with 23 developers and admins. The team delivers through a Dev → FIT → Staging → Production pipeline, plus a training environment that gets back-promoted after every release. Major releases carry 40 to 60 features, with production’s release going out on Thursday nights, after the working day is finished.
Tom Sims owns the releases. He’s been at Paylocity for almost 20 years, joining way back when the company had fewer than 100 employees. He’s watched the Salesforce estate grow from a handful of service users in 2018 to the org it is today. He builds every release, runs every deployment, and picks up whatever can’t be automated afterward.
The team moved from change sets to Copado in 2021, and then to Gearset in 2026. In between sat three years of manual profile work, unpredictable merges, and a repository that grew to roughly 350,000 branches.
Two months in on Gearset, the picture looks very different. Release-night manual steps have gone from an hour and a half at an absolute minimum to around 15 minutes. Tom estimates he has 60% of his release management time back and, more to the point, his evenings back.
Change sets stopped scaling before the team did
Paylocity grew fast and Salesforce grew with it. With six or seven developers and no version control, change sets became the bottleneck.
The issue with change sets is just adding components to change sets is a nightmare. You don’t find out you’re missing a component, until you try to deploy.
Copado solved the speed problem and created new ones
Paylocity evaluated Flosum and Copado in 2021. The technical preference was Flosum, but commercial terms swung in Copado’s favour because they bundled in their robotic testing.
Unfortunately, the robotic testing never worked, even with two teams spending eight months trying before giving up.
Copado did speed up releases at first but then the granularity problem surfaced. Without the ability to select individual changes, two developers working on the same page layout in different sandboxes would overwrite each other’s work.
Less than three months in, the team collapsed down to a single dev box to stop the overwrites.
We had two choices with Copado; go down to a single dev box or constantly make people redo work.
Back-promotes made that worse. Auto back-promotes to individual sandboxes failed silently and left developers to resolve errors manually, so they didn’t. Some sandboxes accumulated hundreds, and in some cases over a thousand, promotes that never happened.
Manual profile steps and merges no one could explain
Profiles were the most expensive problem. Deployments from the dev box overwrote them downstream regardless of what was correct, so field-level security, page layout assignments, record type and Lightning record page assignments, object permissions and Apex class access all came out of the automated process.
That’s roughly 200 profiles, handled by hand on release night. The team “ended up losing a lot of access.”
Merges were another pain. Copado’s auto-merge often reinstated Apex code the team had deliberately removed, on classes explicitly set not to auto-merge, with no conflict raised and nobody to point to. Escalating to Copado support didn’t help.
Between the manual profile work and the all-local test runs that bundling forced onto every release — over 3,000 tests at two and a half hours a run — release nights ran long, and the result still needed checking. Tom puts it at eight out of ten releases where something had to be fixed in staging or production afterward.
With Copado, it was common for me to be up until 2am, 3am, or even 5am trying to fix the release.
A repository with 350,000 branches and no way to clean it up
Copado created a branch for every commit, every deployment, and every merge for bulk release. Nothing cleaned them up.
Every time you committed anything on a story it created a new branch. For every single commit, not for every story.
With hundreds of thousands of branches, Copado supplied a script that deleted one or two at a time. Our team rewrote it to handle a hundred, then worked with a developer to attempt a thousand — and that was only targeting branches over six months old.
When we asked Gearset about the branch cleanup issue we had with Copado. They said, “oh yeah, we automatically clean up all your branches”.
Cutover took hours, not weeks
Timing made the migration tense. The Copado renewal was less than a month away, and missing it meant negotiating an extension with a vendor the team was actively leaving. Then Gearset’s implementation team described the cutover in hours.
The biggest worry was whether we could actually get the migration done in time. Gearset said it was only going to take a couple of hours to cutover.
With Copado, it took us a couple of weeks to get set up. This made me very nervous, but Gearset was right. It was only a couple of hours set up.
The first Gearset release took only 5 minutes
The first release on Gearset was a fast lane release — configuration only, no Apex or flows. Tom was done in just five minutes.
Major releases do take a little longer than 5 minutes, but the shape of the night has changed completely. Deployments run while Tom is away from his desk, and the work left afterward is only what genuinely can’t go through the API.
Manual steps take him 10 or 15 minutes with Gearset. With Copado, he never finished a deployment in less than an hour and a half.
But what Tom cares most about is the time he spends debugging after hours.
There’s been times in the past where my wife is getting up for work and I’m still fixing Copado from the night before. With Gearset, I’m sitting over in the recliner watching TV and she’s like, “are you done?” I’m like, “yeah, a long time ago!”
Governance that holds up to SOX
Paylocity is publicly traded, so access control isn’t a preference.
Access is even more important for us because we are publicly traded. So we have a lot of SOX accountability. And between Git and Gearset, we are able to control the pieces that we need to, and give access to the parts where we don’t.
Under Copado, deployment restrictions relied on a validation rule that anyone who understood it could work around. Gearset’s CD rules and delegated org access replaced that with permissions the team can prove.
Move. Gearset is definitely worth it. It’s so much better, easier, more flexible, and much faster. It’s night and day difference compared to Copado.
