Migrating from Gearset to Serpent without downtime

TL;DR: You do not need a release freeze. Your Git repository is the portable asset, so both tools can be connected to it while you move pipeline by pipeline, lowest environment first and production last. What carries over is the repo, its branches and its history. What gets rebuilt is everything that lived inside the vendor: CI and monitoring jobs, org connections, approval gates, backup schedules and deployment history.

What actually carries over when you switch?

The mental model that makes this easy: metadata lives in Git, orchestration lives in the vendor. Gearset's own documentation describes your repository as where the metadata is stored, with the tool moving it between orgs and that repo. So the asset you spent years building, the commit history and the branch model and the file layout, is yours and stays exactly where it is.

Carries over untouched:

• The Git repository, with every branch, tag and commit.
• Your directory structure and metadata format, as long as the new tool reads it.
• Branch protection rules and reviewer lists, because those live in GitHub, GitLab or Bitbucket.
• Anything already expressed as code: scripts, Apex tests, static analysis configuration.

Has to be rebuilt:

• CI/CD job definitions and their schedules.
• Change monitoring jobs and their notification rules.
• Org connections and authenticated users, per environment.
• Approval gates and the rules for who can promote to production.
• Backup schedules, and any retained backup data, which is not portable between vendors.
• Deployment history and audit records held inside the old tool.

What should you check before you connect anything?

Confirm your metadata format first. Gearset commits in SFDX source format when it initialises an empty repository and supports metadata API format as well, so an inherited repo can legitimately be in either. A format mismatch is the one thing that turns a quiet parallel run into a wall of false diffs.

If the repo is in metadata API format and you want to convert, do that as its own change: convert, review, merge, verify a deployment from it. Never convert format and switch tooling in the same week. You will not be able to tell which change caused which surprise.

How do you keep releasing while both tools are connected?

1. Inventory what the old tool does for you. Deployments, CI jobs, change monitoring, backup, code review, sandbox seeding. That list is your migration backlog and it is usually longer than anyone remembers.
2. Connect the new tool read-only. Point it at the same repository and the same orgs and run comparisons without deploying. Nothing changes for the team on day one.
3. Rebuild the lowest environment first. Dev or integration. Let one squad ship through the new pipeline for a sprint while everyone else stays on the old path.
4. Run both for one full release cycle. The new pipeline validates every change, the old one still deploys. Every difference between the two results is a configuration gap you found for free.
5. Move UAT and staging. By this point the pipeline shape is proven, the approval model is agreed and the audit output looks the way your reviewers expect.
6. Move production last, inside a normal change window. There is no cutover event, only the last environment moving.
7. Decommission on a delay. Keep the old subscription through at least one backup retention period, then revoke org connections and remove deploy keys and webhooks.

What are the traps in a parallel run?

• Two writers, one branch. Agree that only one tool commits to a given branch at a time. Racing commits are the most common self-inflicted wound in a migration.
• Duplicate status checks. Both tools will want to report on pull requests. Make only one of them a required check, or merges stall waiting on a pipeline you are retiring.
• Double deployment. If both tools have a scheduled job pointed at the same target org, you will deploy twice. Disable the old schedule the moment the new one goes live, not the week after.
• Backups. Backup data generally cannot be exported into another vendor in a restorable form. Decide your retention position before you cancel anything.
• Audit gaps. In a regulated environment, export the deployment history you are required to keep while the old contract is still active.

How long does the whole thing take?

The constraint is your release cadence, not the tooling. A team on a two-week cycle is usually through in two cycles: one parallel cycle and one production cycle. Serpent setup takes under 15 minutes per workspace and onboarding sessions with our team are free, so most of the calendar is spent waiting for your own change windows rather than configuring anything.

Why do teams switch in the first place?

Three reasons come up repeatedly. Pricing that moves with users and with the number of CI/CD orgs. A workflow that assumes Git fluency the admin half of the team does not have. And package delivery that is a separate purchase. Serpent prices flat per company, runs a ticket-based workflow with Git in the background, installs nothing in your org, and includes 1GP, 2GP and AppExchange release workflows on every plan including free Essentials. More switching playbooks live in our SF Guides library.

FAQ

Do we need a release freeze to switch?

No. Rebuild environments one at a time and keep the old pipeline deploying until the new one has validated a full release cycle.

Can two DevOps tools be connected to the same repository at once?

Yes, and that is what makes a no-downtime switch possible. The rule that keeps it safe is one writer per branch at any given time.

Do our existing backups move across?

No. Backup data is not portable between vendors in a restorable form, so plan an overlap that covers your retention requirement.

What happens to our deployment history?

It stays with the old tool. Export whatever your auditors need while the contract is still active.

Does Serpent install anything in our Salesforce orgs?

No. It connects over standard APIs only, so there is no package to approve on the way in and nothing to uninstall later.