Plan a NetSuite divestiture migration from an approved business and data perimeter, then test how the separated operation will work on its first independent day. Determine which records, obligations, shared services and historical access belong with each party. A subsidiary filter is a useful technical selection tool, but it is not a substitute for the legal and operational separation decision.
This guide concerns execution planning after the appropriate owners define the transaction's requirements. Legal advisers, finance and the deal team decide ownership, permitted disclosure, accounting treatment and contractual obligations. The migration team turns those decisions into controlled data, access and operating boundaries.
List the entities, business units, processes and records in scope. Identify the effective dates and any differences between legal completion, operational cutover and service transition. Those dates may not be interchangeable.
Create explicit rules for inclusion, exclusion and shared material. A customer may trade with both the sold and retained businesses. A file attached to a relevant transaction may contain unrelated information. The team needs a decision for those cases rather than a blanket export.
Give each rule an accountable business or legal owner and retain its approval. Technical staff should not infer data-sharing rights from a record's department label or the buyer's interest in receiving a complete history.
Mark unresolved perimeter questions as holds. If the ownership or disclosure decision is unclear, separate the affected records for review instead of copying them broadly and attempting to remove them later.
Identify customers, vendors, items, contracts, employees, bank arrangements and applications shared across the perimeter. Determine which attributes can move, which must remain and which need separate identities in the target design.
Keep identity matching distinct from data entitlement. Two companies may need to refer to the same supplier, but that does not establish a right to share all commercial terms, bank details or historical communications.
Map shared services such as payroll, purchasing, treasury, warehousing and reporting. The separated business may rely on transitional support for a period. Record the service owner, permitted data exchange, deadline and evidence required to exit that arrangement.
Include external contracts and application access. A working integration in the seller's environment does not automatically belong to the new operation. Authorized owners must confirm the supported account, licensing and access arrangements before the migration depends on them.
Identify the essential transactions the separated business must perform immediately: order entry, shipment, billing, purchasing, payment or required reporting. Define the minimum complete process for each, including exceptions and authority.
Decide the target environment and organizational design with the responsible solution and finance owners. A fresh account, an existing buyer account and a transitional arrangement have different migration and access implications. Do not assume copying a subsidiary recreates its entire operating context.
Confirm required users, roles, features and environments. Test access using the intended people and organizational boundaries. A working administrator session does not prove that the separated team can operate without seeing retained-business data.
Keep temporary processes visible. If a service remains with the seller for a defined period, specify how requests, approvals, data exchanges and reconciliations will work until the independent process is ready.
Separate operational opening data from historical evidence. The business needs actionable open orders, obligations and stock, but it may not need every historical record recreated as a live target transaction.
For each dataset, document selection rules, record grain, relationships, permitted fields and approved recipients. Include attachments and custom records that support the required history. Do not assume a transaction export captures every linked document or contextual record.
Review the export tool's actual coverage. Even a feature labeled full export can have limits; NetSuite's Full CSV Export does not export all account data. Use the supported sources required for the approved package and verify completeness against the specific inventory.
Protect retained-business information throughout preparation. Redaction and separation need verification on the actual output, including free text, files, reports and shared references. A filter that correctly selects a transaction can still leave unrelated details inside its attachment.
A fictional source review classifies 18,000 transactions: 6,200 relate solely to the sold business, 11,000 solely to the retained business and 800 need shared-record review. These groups sum to 18,000, but the 800 are not automatically approved for either party's complete dataset.
The master-data review identifies 300 supplier records: 120 used only by the sold operation, 80 only by the retained operation and 100 used by both. The shared supplier identity does not settle which fields or historical documents each party may receive.
Authorized owners approve record-specific rules for the shared population. Some records can be included with limited attributes; others require separate extracts or retained access through a defined service. The migration team implements those decisions and tests both permitted inclusion and prohibited disclosure.
Target record counts may differ from source counts when the approved design creates separate identities or representations. The reconciliation therefore explains the transformation rather than forcing equal counts without regard to the agreed perimeter.
Finance should approve which balances, open receivables, payables, inventory and other obligations establish the new operating position. The migration team preserves the source evidence, mapping and target references needed to verify that decision.
Keep open operational work consistent with the balances. A partially received order, an unpaid bill and the related stock may require coordinated treatment. Recreating completed movements can duplicate inventory or obligations.
Separate the migration reconciliation from purchase-price, tax or legal allocation decisions. Those specialist decisions may supply inputs to the target design, but an import procedure does not establish their correctness.
Use the approved currency and date basis for each comparison. Retain explanations for intentional differences and keep unresolved differences visible rather than posting unexplained adjustments to make the split balance.
Run representative Day One scenarios with the proposed users, data and interfaces. Verify that the sold operation can complete its work and that the retained operation continues correctly where it remains in scope.
Include denied-access and wrong-recipient tests. A successful transaction is incomplete evidence if the new team can also access confidential retained-business records. Inspect reports, attachments and connected destinations as well as ordinary forms.
Test transition failure. If a shared service is unavailable, establish who can diagnose it, which work is held and what approved alternative exists. Record the boundary beyond which a rollback would require business reconciliation rather than a simple configuration reversal.
Measure the final extraction, review, loading and acceptance work against the available window. Shared-data review can become a critical dependency and should not be left as an unestimated cleanup step.
At cutover, transfer writing authority and reconcile in-flight work. Confirm which system accepts new transactions and how legitimate late source changes are handled. Avoid allowing both parties to update the same shared population without a defined protocol.
Retain historical access through the approved archive or service arrangement. Test the questions each authorized audience must answer and the restrictions that remain applicable. Do not terminate access before the required evidence is usable.
Track each transitional service to its agreed exit evidence and responsible owner. Removing an integration or account prematurely can interrupt operations, while leaving it indefinitely can preserve inappropriate access or duplicate work.
A separation-planning review with CuriousRubik's NetSuite support services can help connect the approved perimeter to practical account and migration tests. The desired outcome is an independently workable operation with an explainable data boundary, supported by the necessary legal, finance and business decisions.
That may identify part of the population, but shared records, attachments, cross-entity activity and contractual rights need separate review. The approved business perimeter must drive the technical selection.
The authorized legal, finance and transaction owners determine the permitted scope. The migration team implements and verifies those decisions rather than inferring rights from record access.
No. The Full CSV Export feature does not export all account data. Define the required datasets and relationships, select supported extraction routes and verify the actual package.
Not always. Approved separation can change identities or representation. Reconcile the transformation and explain inclusions, exclusions and shared-record treatment instead of forcing equal counts.
When its agreed replacement, continuity, reconciliation and access conditions are met and the responsible owners authorize exit. A target system being online does not prove every shared dependency is ready to end.