TSA Exit Acceleration
Off the seller’s Databricks account. On budget.
Fixed-fee proposal in 48 hours. Senior team on day one. The first conversation is always free.
Databricks TSA separation is the work of standing up a Newco account, workspaces, and Unity Catalog metastore, moving the lakehouse data, and repointing the jobs and notebooks that run the business before the seller's cloud subscription becomes the thing holding the carve-out together. The work sits inside the broader carve-out advisory program because the lakehouse feeds analytics, machine learning, and operational pipelines that finance and operations depend on daily.
Databricks separation starts with a full inventory of the seller account. The buyer needs the workspace layout, the Unity Catalog metastore and its catalogs, schemas, and tables, the cluster and SQL warehouse inventory, and the cloud provider underneath. Databricks runs on the seller's own cloud subscription, so the platform is bound tightly to the seller's storage accounts, networking, and identity. The separation is therefore a joint exercise across Databricks and the underlying cloud.
The seller typically runs Newco workloads in shared workspaces, with Newco data in shared catalogs separated by grants. The clean end state is a Newco account with its own workspaces and a Newco metastore in Newco's cloud subscription. A shared seller workspace is acceptable only as a bridge during the TSA, because compute, governance, and storage all sit in the seller's cloud otherwise, keeping Newco entangled.
Target strategy follows the cloud separation. Where Newco is establishing its own cloud subscription, the Databricks account and metastore are provisioned there and the lakehouse data is moved into Newco storage. Where Newco temporarily shares the seller's cloud, the Databricks exit waits on the cloud account split. The decision drives the data move mechanism and the cutover window.
A clean inventory and a settled workspace decision drive the downstream sequence: the data move, the catalog rebuild, the job cutover, and the consumer migration. The pattern aligns with the broader Snowflake and Databricks separation framework and with the underlying cloud account separation.
Databricks is sold as consumption against a committed spend, billed in Databricks Units on top of the underlying cloud compute that Newco also pays its cloud provider for. The seller commitment does not transfer. Newco signs a direct agreement sized to its own consumption profile, and the buyer models projected Newco usage from the seller telemetry attributable to Newco workloads before negotiating a commit.
The buyer separates two costs that are easy to conflate: the Databricks platform charge and the raw cloud compute charge. Both move to Newco, and both need governance. Leverage in the Databricks negotiation comes from a credible alternative, whether a competing lakehouse or a more conservative commit, and from term and ramp structure. A pay as you go starting period lets real Newco consumption inform the commitment rather than a guess made under deal pressure.
Where the seller hosts Newco workloads through a TSA period, the pricing is cost-plus or fixed-fee with a defined exit ramp and a consumption allocation Newco can audit. The seller cannot mark up compute it does not separately incur, and the TSA defines how Databricks Units and cloud compute are metered so Newco is not absorbing seller overhead.
Where a partner is engaged for the migration, the contract is fixed fee for defined deliverables with disciplined change control. The audit discipline runs through the broader TSA license consolidation work.
Databricks stores table data as Delta files in cloud object storage, so the data move is partly a cloud storage move. Managed tables live in the metastore's storage, while external tables point at defined storage locations. The migration mechanisms include Delta deep clone across storage accounts, cloud native object copy, and converting managed tables to external tables to control where data lands. The buyer chooses by table type, volume, and whether Newco's cloud is the same provider as the seller's.
The Unity Catalog metastore is rebuilt rather than copied blindly. Catalogs, schemas, tables, views, and volumes are recreated in the Newco metastore, with grants reconstructed to match a standalone governance model. Storage credentials and external locations are repointed at Newco storage with Newco's own service principals. Lineage, tags, and any data classifications are recreated so governance controls survive the move.
Code assets are the next layer. Notebooks, Databricks workflows, Delta Live Tables pipelines, and repos often hard reference storage paths, secrets, mount points, and service principals that all change in Newco's environment. Each is inventoried and updated, and secrets are reissued in Newco's secret scope rather than copied from the seller.
Machine learning assets carry their own dependencies. Registered models, feature tables, and MLflow experiments are migrated where they hold value, with model serving endpoints rebuilt against Newco compute. The discipline mirrors the broader TSA exit data migration strategy.
The lakehouse is only as separable as the pipelines that feed it and the tools that read it. The ingestion side includes streaming sources, change data capture feeds, batch loads from source systems, and partner data shares. Each ingestion path is repointed at the Newco workspace with new credentials and new storage targets. Where ingestion tools sit under their own TSA, the Databricks cutover sequences with those exits.
The consumption side is broader. BI tools querying SQL warehouses, the finance reporting layer, data science workloads, reverse ETL into operational systems, and any application reading Delta tables connect through workspace URLs, tokens, and connection strings that change at cutover. The buyer inventories every consumer, including the informal ones analysts built, so nothing breaks silently after the switch.
Orchestration is repointed. Jobs scheduled inside Databricks workflows or in external orchestrators are recreated with Newco service principals and Newco cluster policies. Cluster policies and instance pools are reconfigured for Newco cost governance so the new environment does not over provision compute from day one.
Identity is the final piece. Single sign on, SCIM provisioning, and personal access token policies are reconfigured against Newco's identity provider so users and service principals authenticate cleanly from the first job run.
Cutover moves ingestion and consumption from the seller workspace to the Newco workspace. The runbook covers the final data sync, the freeze on writes to the seller copy, the repointing of ingestion jobs, the consumer reconnection, and the validation gate. Because the lakehouse supports analytics and pipelines rather than live transactions, the cutover usually runs as a controlled switch with parallel running where downstream accuracy demands it.
Validation is the heart of the cutover. Row counts, key metric reconciliation, and report parity confirm that the Newco lakehouse produces the same numbers as the seller source for the same period. Pipeline output is compared run for run. A finance close or operational process that depends on the lakehouse cannot move until parity is signed off against named outputs rather than a successful copy alone.
Stabilization runs thirty to sixty days. Cluster policies and budget alerts confirm consumption tracks the model. Failed jobs, stale pipelines, and access gaps are triaged within agreed service-level commitments. Only after a clean processing cycle does the buyer certify the lakehouse for TSA exit.
Decommissioning is explicit. Once the Newco workspace is validated and the TSA tail closes, the seller removes Newco catalogs and revokes access so Newco data no longer persists in the seller's cloud.
Databricks separation cost is driven by compute consumed during the move and by the cloud egress of moving large Delta tables between storage accounts or regions. Dual running and reload jobs both add to the bill. The discipline is to set cluster policies, budget alerts, and defined transfer windows so the heavy work does not run open ended. Egress between cloud regions deserves explicit modeling because it can dominate the cost of a large lakehouse move.
The common failure mode is treating Databricks as separable from the cloud beneath it. The platform, the storage, the networking, and the identity all move together, so a Databricks exit that ignores the cloud account split stalls. Buyers that sequence the lakehouse exit with the cloud separation avoid that deadlock.
The second failure mode is underestimating hard coded references in notebooks and jobs. Storage paths, secrets, and service principals embedded in code break quietly at cutover. The fix is a code inventory and a parameterization pass before the move. A PMO maintains the dependency map across the lakehouse, the cloud, and the connected tools, escalating blocks inside forty eight hours.
A clean Databricks separation produces a Newco that owns its own account, its own metastore, and its own cloud spend, with the optionality to evolve the data and ML architecture on its own timeline. The discipline runs through the TSA exit acceleration program under a Fixed Fee plus Portfolio Retainer engagement model.
Yes. The clean end state is a Newco account with its own workspaces and a Newco Unity Catalog metastore in Newco's cloud subscription. A shared seller workspace is acceptable only as a bridge during the TSA because compute, governance, and storage all sit in the seller's cloud otherwise.
Databricks stores table data in cloud object storage, so the separation includes moving or repointing the Delta tables in the seller's storage account to Newco's. Deep clone, cloud native copy, and managed to external table conversion are the common mechanisms depending on table type.
Untangling jobs, notebooks, and Unity Catalog grants that reference seller cloud resources. The notebooks and workflows often hard reference storage paths, secrets, and service principals that all change in Newco's environment.
Most buyers plan four to nine months. The platform move can be quick, but the dependent ingestion pipelines, ML workflows, and downstream consumers set the real pace, and they have to be sequenced with the cloud account separation.
Account strategy, data sharing cutover, replication, and the RBAC rebuild.
Read the article →The cloud account separation that the lakehouse exit depends on.
Read the article →The data migration framework, validation gates, and reconciliation discipline.
Read the article →The 90-day governance, IT, finance, HR and procurement separation plan we run on live carve-outs. Get the playbook plus the bi-weekly Day One Letter — short, signal-heavy, buyer-side.
No spam. Unsubscribe in one click. · Read the overview first →
Fixed-fee proposal in 48 hours. Senior team on day one. The first conversation is always free.
Seven buyer-side moves to exit a Transition Services Agreement on time and below budget. The mark-up, the extension-fee curve, exit sequencing, and the 11-month calendar.
One tactic, one benchmark, or one pattern from a recent buyer-side engagement. Short. Signal heavy. Free.
Subscribe to The Day One Letter →Scope the data split tightly. Every table you over-migrate and every pipeline you leave on the seller is a line on next year's TSA invoice.