Salesforce Is Retiring Your Edition. Here's What the Forced Move Actually Involves.

CWT Studio · July 2026

If your Salesforce account executive has told you that your edition has reached end of sale, or your renewal came with a deadline and a menu of upgrade options you never asked for, you're inside a wave that's been building all year. Salesforce is winding down its legacy editions and older orgs, and the customers on them, mostly small and mid-sized businesses, are being moved to the current lineup: Starter Suite, Pro Suite, or Enterprise. This post explains what's actually happening, what the move involves beneath the sales conversation, and where the real costs and risks live, based on running these migrations for the businesses going through them.

What's happening, as best anyone can verify

The pattern in 2026 has a distinctive shape: customers hear about retirement from their account executive before anything official appears in writing. Professional Edition is the clearest case. Customers have been told it reached end of sale on April 1, 2026 with full retirement to follow, and the edition has disappeared from Salesforce's public pricing pages, while the official list of editions no longer sold has yet to catch up. Essentials, the previous small-business edition, already has a formal migration path to Pro Suite documented in Salesforce Help. Around the editions themselves, the platform is retiring legacy infrastructure on a published schedule: old instance-based URLs, legacy chat, the old Outlook integration, and the aging orgs that depend on them.

The practical takeaway costs nothing to accept: if your org is old enough that you're reading this, the question is when you move, and on whose timeline. Waiting converts a planned migration into a deadline migration, and deadline migrations are where data gets lost.

The part the upgrade conversation skips

An edition change sounds like flipping a plan on a billing page, and for some customers that's the whole event. For many legacy orgs it means a brand new org, a fresh, empty Salesforce with none of your data in it, and the move is a genuine data migration: every account, contact, deal, note, and years of logged activity has to be exported from the old system and rebuilt in the new one. Three realities govern that project, and each one surprises the teams who hit it.

Your old org limits how the data can leave. Legacy editions often have no API access, which rules out the modern migration tooling and leaves the built-in export service, which on older orgs runs monthly, produces a zip of CSVs, and deletes the download after 48 hours. Your migration plan has to be built around when that export can run and what it contains. We've planned entire cutover schedules around a single monthly export window.

The new edition may lack features your old org used every day. This is the costliest category of surprise, because it appears after the money is spent. As one example from a recent migration: the modern Notes feature depends on an engine that Salesforce now ships switched off in all new orgs, and the Starter edition provides no way to switch it on, so a business with twenty years of notes needed an engineered workaround to make its own history visible. Field limits, page customization, and reporting depth all differ by edition, and the differences surface after the data has landed. The time to map your old org's daily habits against the new edition's actual fences is before you sign, since the sales conversation reliably covers the new edition's additions, and the removals tend to surface on their own after cutover.

The relationships between records are the real workload. Exporting the records themselves takes an afternoon, while preserving the connections among them, which contact belongs to which company, which deals belong to which contact, which of ten thousand logged emails belongs to whom, consumes the project, and it's where amateur migrations quietly fail. The technique that makes it safe is carrying every record's old ID into the new org as an external key, which makes every load repeatable, every gap patchable, and every later correction possible. Migrations done without that key produce duplicates on every follow-up load, and there is no clean way to retrofit it afterward.

Choosing among Starter, Pro Suite, and Enterprise

The honest sorting logic is shorter than the pricing pages suggest. Starter Suite, at $25 per user, fits teams that live in accounts, contacts, deals, and activity history, and can accept real constraints on customization in exchange for the price. Pro Suite fits teams that hit Starter's fences on fields, page control, or feature availability and want them removed without enterprise overhead. Enterprise fits organizations with integrations, automation depth, or compliance needs that justify its cost. The mistake to avoid is choosing by feature checklist alone: choose by mapping what your team actually does daily in the old org, then confirming each habit survives in the candidate edition. A day of that mapping is cheaper than discovering a missing feature after cutover.

A planning sequence that works

Run the move in this order. Take the export early and inventory what you actually have, since the counts drive everything. Map daily habits against the target edition's limits and resolve the gaps on paper first. Migrate with external keys on every object. Pilot with a handful of records before loading thousands. Keep the old org readable until a patch import has caught everything created or changed during the transition, and tell your team a hard date after which the old system is history. Then verify against named records your team cares about, since "the load succeeded" and "Maggie's record is right" are different claims, and the second one is the claim your team actually lives with.

When to get help

Plenty of teams can run this themselves with patience and a careful sequence. The cases that justify bringing someone in are specific: an old org with no API and a lot of relationship data, a team with no admin and no appetite to become one, history that matters commercially, or a retirement deadline that removed the runway a careful DIY needs. We work on exactly these migrations, on exactly these editions.

CWT Studio is a systems practice for small businesses on Salesforce. We verify before we promise, we document what we find, and we land migrations clean. If your edition is being retired, start at thecwtstudio.com.