Salesforce ISVs: Why Migrate from 1GP to 2GP Now

Why Should You Care About 1GP to 2GP Migration?

If you’re running a managed package on the AppExchange and haven’t thought seriously about migrating from First-Generation Packaging (1GP) to Second-Generation Packaging (2GP), you’re not alone. Most ISV executives we speak to put it in the “important but not urgent” bucket: a technical upgrade that can wait until things slow down.

Here’s the problem: things don’t slow down, and the longer you wait, the more you’re paying for that delay in release costs, developer time, integration risk, and missed revenue.

TL;DR:

– Ship faster → monetize features sooner.

– Cut “1GP tax” → less release overhead, fewer incidents, lower support burden.

– Unlock platform capabilities → External Client Apps require 2GP (a hard constraint).

Let’s talk about why this migration belongs on your near-term roadmap, and what the business case actually looks like.

1GP vs. 2GP: What Executives Need to Know

You don’t need to understand the internals of Salesforce packaging to make this decision, but a rough mental model helps.

1GP (First-Generation Packaging): your “source of truth” is a packaging org, releases involve manual, org-dependent steps, and automation tends to be brittle.

2GP (Second-Generation Packaging): your “source of truth” is your repository, and package versions are built programmatically so they are repeatable, auditable, and automatable.

The migration from 1GP to 2GP isn’t about chasing new technology for its own sake. It’s about removing a structural drag on your business.

The Business Case: Where the Money Is

Speed → faster releases, faster revenue

Every feature that sits in your backlog is delayed revenue. With 1GP, releasing a new feature or a new edition tier involves manual packaging steps, careful org management, and meaningful coordination overhead. A release that should take an afternoon can stretch into days.

With 2GP and a properly configured CI/CD pipeline, that same release can be built, tested, and pushed repeatedly with a script. In practice, teams often shorten release cycles meaningfully once packaging stops being the manual bottleneck.

If you’re planning to monetize a new feature, launch a new edition, or respond to a competitive threat, packaging velocity matters. Every sprint that ends with “it’s done, but we can’t ship yet” is lost revenue.

Cost & risk → the “1GP tax” hits margin, support, CSAT, and NPS

Release overhead and incident risk are two sides of the same coin in 1GP: manual, org-centric packaging increases both operational cost and the probability of human error.

What this looks like in real P&L terms:

• Release overhead is a real cost: manual packaging steps require experienced engineers, careful sequencing, and institutional knowledge that often lives in 1–2 people (key-person risk).
• Breaking changes become more likely: a field accidentally deleted, a dependency missed, or a change made in the wrong place can lead to a broken package version and unplanned support load.
• Support + reputation impact: fewer incidents means lower support costs, fewer escalations, and a healthier customer experience (including CSAT and NPS).

Platform constraint → External Client Apps (ECAs) require 2GP

Here’s where this becomes genuinely urgent for ISVs whose apps integrate with external systems.

If your application uses a Connected App for authentication, whether for a backend service, a third-party integration, or your own multi-tenant architecture, Salesforce’s direction is clear: Connected Apps are the past, External Client Apps (ECAs) are the future.

ECAs offer meaningful improvements: better security posture, per-subscriber customization, proper support for scratch org development, and faster propagation of changes. Salesforce has been explicit that ECAs represent the next generation of app interoperability on the platform.

The critical constraint: External Client Apps cannot be added to 1GP-managed packages. This isn’t a temporary limitation; it’s an architectural constraint. The Salesforce Metadata Coverage documentation confirms that the ExternalClientApplication metadata type is not supported in 1GP packages.

In practical terms, this means that if you want to adopt ECAs, whether to improve your security architecture or to prepare for Salesforce eventually sunsetting Connected Apps, you must first migrate to 2GP. The alternative is to create a dedicated 2GP package, which adds technical debt and increases the onboarding burden for customers, so it’s not recommended.

This is not a hypothetical future problem. If you’re building against Connected Apps today, you’re accumulating technical debt with a deadline. The window to plan this migration on your own terms, instead of under pressure, is open right now.

We covered the details of External Client Apps and what makes them superior to Connected Apps in our earlier deep dive. Worth a read if your app relies on any kind of external authentication.

What this means for ISVs at different stages

Early-stage ISVs: if you still manage packaging mostly “in-org,” moving to 2GP may also mean adopting the basics of modern SDLC (version control, scratch orgs, release discipline). That’s an investment, but it buys you a repeatable release process that doesn’t depend on tribal knowledge, and it reduces incident risk that can otherwise consume weeks of a small team’s capacity.

Mature ISVs: if you already run CI/CD and work repo-first, the ROI is more direct: you remove the last org-dependent step in the pipeline. Releases become faster, cheaper, and less risky, and shipping feature tiers becomes easier operationally.

In both cases, the migration needs to be done with continuity and upgrade safety in mind. Existing subscriber orgs need to upgrade seamlessly: that’s not optional when you’re a managed package ISV, and it’s one of the most technically sensitive aspects of the process.

What a Migration Looks Like in Practice

Aquiva Labs offers a 1GP to 2GP Package Migration engagement that addresses the full scope of this transition:

• 2GP Migration – migrating your managed package with continuity and upgrade safety as the primary constraints. Your subscribers should never feel it.
• Partner Business Org Configuration – enabling Package Visualizer on your PBO so your team has visibility into package contents and dependency impact before any change ships.
• SDLC Modernization Advisory – practical guidance on repository strategy, scratch org usage, and release discipline tailored to your team’s current capabilities. Not theoretical best practices, but actionable guidance grounded in what actually works for AppExchange ISVs.

For teams ready to go further, we also offer CI/CD Pipeline Modernization and Connected App to External Client App Migration as extensions of the core engagement.

The Clock Is Running

If you’re running 1GP today, you’re not in crisis, but you are falling behind, and the gap is widening with every release cycle.

The best time to start this migration is when you have the runway to do it carefully. That time is now.

If you’re an AppExchange ISV and want a clear 1GP to 2GP migration path for your specific package, let’s talk.