Nov 2026 · By Somesh Motupally · 6 min read

Harness FirstGen to NextGen: Migrating the Platform Without Losing the Security Gates

The problem

Our Harness estate grew up on FirstGen. That's where the pipelines live, where the delegates run, and — most importantly for us — where the account-level security templates live: the versioned, centrally maintained building blocks that put secret scanning, SAST, dependency scanning, and image scanning into every team's pipeline by default. That template system is the reason our security coverage is consistent instead of aspirational.

NextGen is where Harness has been investing for years, and FirstGen is in maintenance. So the question was never really whether to migrate. It's how — because a careless migration doesn't just move pipelines, it quietly drops the gates. The worst migration outcome isn't a broken build. It's a build that succeeds with the scanning silently missing, discovered months later by an auditor instead of by you.

Why a lift-and-shift doesn't work

FirstGen and NextGen are not two versions of the same product. They're two different platforms that happen to share a logo. NextGen is YAML-first with Git Experience as a core workflow; it organizes everything under an account → organization → project hierarchy that FirstGen doesn't have; the expression language, the delegate model, the connector model, and the template library are all their own things. Harness ships migration tooling, and it earns its keep on bulk, well-structured estates — but no converter changes the fact that the target model is different.

Templates are the sharpest example. A FirstGen template and a NextGen template solve the same problem — reusable, versioned pipeline logic — with different primitives, different scoping, and different ways of passing inputs. The intent of our template set ports perfectly. The syntax doesn't port at all. Anyone who budgets a FirstGen-to-NextGen move as a format conversion is budgeting for the wrong project.

The approach: platform first, templates second, pipelines last

The order matters more than the tooling. Ours runs in four stages:

• Inventory before anything moves. Catalog every pipeline, template, trigger, connector, secret, and delegate in FirstGen — and mark what's actually still used. Every long-lived platform has dead pipelines nobody dares delete. Migration is the cheapest audit you will ever get: don't pay to move pipelines that should be retired.
• Rebuild the platform layer. Delegates get registered in NextGen, connectors get recreated, secrets get re-homed in the new hierarchy. Nothing glamorous — but every pipeline migration stalls here if this layer isn't solid first.
• Rebuild the templates before the pipelines that consume them. The security template set — secret scanning with Gitleaks, SAST, SCA with SBOM generation, Trivy image scanning — gets re-expressed in the NextGen template library, with the same parameters and the same failure thresholds. This is the step that protects the gates: a pipeline that lands in NextGen should land on gated defaults from its first run, not get its controls re-attached later.
• Pilot, then move in waves. Low-risk pipelines first, run in parallel against FirstGen until the outputs match — same scans, same gates, same failure behavior. Only then do production pipelines move, team by team, with FirstGen kept readable as the reference until parity is proven.

Notice what's not on that list: a big-bang cutover weekend. Platforms that took years to build don't move in a weekend, and the attempt is exactly how security controls end up "temporarily" disabled and permanently forgotten.

Lessons learned

• Migrate the control plane, not the pipelines. Pipelines are consumers. If the templates, connectors, and secrets are right in NextGen, each pipeline move is a small, boring event. If they're not, every move is a bespoke rescue.
• The versioning discipline transfers even when the syntax doesn't. Pinning template versions and letting teams upgrade on their own schedule is what made the FirstGen template system work. That contract matters more than any individual template — rebuild it first.
• Parity is a test, not a hope. "The pipeline runs" is not migrated. Migrated means the same gate fails the same bad build in NextGen that it failed in FirstGen. Prove it with a deliberately failing build before you call any pipeline done.
• Retire during migration, not after. Every dead pipeline you move is cost with zero benefit, and you'll never get a cleaner moment to delete it than while you're already justifying its existence.

What's next

The end state we're aiming at is unglamorous and exactly right: the same security baseline, enforced the same way, on the platform that has a future — with the template set still the single place a new control gets added once and inherited everywhere. The platforms change. That design principle is the thing worth migrating most carefully.

If you're mid-migration from FirstGen, I'd like to hear what surprised you — get in touch.