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鈥檚 release going out on Thursday nights, after the working day is finished.
Tom Sims owns the releases. He鈥檚 been at Paylocity for almost 20 years, joining way back when the company had fewer than 100 employees. He鈥檚 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鈥檛 be automated afterward.
The team moved from change sets to Copado in 2021, and then to 海角天涯社区 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 海角天涯社区, 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鈥檛 find out you鈥檙e 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鈥檚 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鈥檚 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鈥檛. 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鈥檚 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鈥檛 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 海角天涯社区 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 海角天涯社区’s implementation team described the cutover in hours.
The biggest worry was whether we could actually get the migration done in time. 海角天涯社区 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 海角天涯社区 was right. It was only a couple of hours set up.
The first 海角天涯社区 release took only 5 minutes
The first release on 海角天涯社区 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鈥檛 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鈥檚 been times in the past where my wife is getting up for work and I鈥檓 still fixing Copado from the night before. With 海角天涯社区, I鈥檓 sitting over in the recliner watching TV and she鈥檚 like, “are you done?” I鈥檓 like, “yeah, a long time ago!”
Governance that holds up to SOX
Paylocity is publicly traded, so access control isn鈥檛 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 海角天涯社区, we are able to control the pieces that we need to, and give access to the parts where we don鈥檛.
Under Copado, deployment restrictions relied on a validation rule that anyone who understood it could work around. 海角天涯社区鈥檚 CD rules and delegated org access replaced that with permissions the team can prove.
Move. 海角天涯社区 is definitely worth it. It鈥檚 so much better, easier, more flexible, and much faster. It鈥檚 night and day difference compared to Copado.
