Central coordination needs local evidence before identities are combined.
A Singapore shared-service team should coordinate the migration decision without becoming the assumed authority for every country's customer, supplier and item data. The key question is which source identities represent the same business thing, which merely look similar and who can approve the distinction. Settle those questions before a bulk transformation turns an uncertain match into a permanent mapping.
This is especially important when regional finance wants one customer view while country teams transact with different legal buyers. A common brand, email domain or supplier code can be useful evidence. None should be treated as a sufficient merge instruction on its own.
Three collisions in an illustrative regional migration
Consider a fictional distributor moving country records into a shared NetSuite environment coordinated from Singapore. Its migration team finds three apparently simple cleanup opportunities.
The Singapore sales file contains a customer called “Harbour Retail,” and the Malaysia file contains the same trading brand. The first has orders from a Singapore legal buyer; the second has orders from a separate Malaysian legal buyer. A central matching rule proposes one customer because the display names and brand website match.
The supplier files both contain code V100. In Singapore, the code belongs to a packaging supplier. In Thailand, it belongs to a facilities contractor. The code was unique within each source system, but never intended to be unique across the group.
Finally, two item records share the description “standard carton.” One source sells it by carton; the other uses the description for a single inner pack. A text-based match could combine records whose ordering units differ.
All names and codes in this scenario are invented. The point is the decision: customer brand identity, source-system identity and physical item identity require different evidence. A single duplicate percentage would obscure those distinctions.
Use an adjudication pack rather than a cleanup spreadsheet
For each candidate match, create a compact decision record. Include the source system and entity, original key, proposed target treatment, evidence, affected open transactions, decision owner and approval date. Preserve the original values even when the target will use standardized spelling.
The customer case should hold the legal-buyer evidence from each country owner, the contract or order references establishing who buys, and the invoicing attributes finance has validated. The proposed disposition is “retain distinct legal-buyer identities; link for group analysis through an approved design.” The technical team must then determine the supported NetSuite representation for the account.
For V100, retain two source identities by qualifying the code with its originating system or entity. The migration crosswalk might use SG_SOURCE:V100 and TH_SOURCE:V100 as illustrative external reference labels. These are suggested mapping conventions, not required NetSuite field formats. They prevent the transformation from overwriting one supplier with another simply because their local keys match.
For the carton case, the product owner and warehouse owner must establish the actual unit relationship and whether the products are interchangeable. If evidence is missing, hold the affected records from the relevant transaction process. Do not invent a conversion factor to keep the import moving.
Give each decision a pair of owners
Assign a business meaning owner and a migration execution owner. The meaning owner decides whether the proposed identity and operating attributes are correct. The execution owner implements the approved mapping, tests it and reports exceptions. Singapore shared services can chair the queue and resolve scheduling conflicts without replacing either responsibility.
In the fictional customer case, country finance confirms the legal buyer and local invoicing needs, while the regional commercial owner confirms the desired brand-level reporting. Their answers may support distinct transaction identities plus a reporting relationship. A wish for one regional dashboard should not erase which entity owes a receivable.
For supplier identity, procurement establishes the contracting party and finance reviews payment-related data through its separately approved controls. Keep sensitive payment credentials out of the general migration discussion pack. The team can record that verification was completed and where authorized reviewers can find the evidence without copying full banking data into every worksheet.
For items, operations establishes packaging and fulfilment meaning, while finance confirms relevant accounting classifications. Where owners disagree, record the exact unresolved question. “Data team to fix” is not an accountable decision when the data team lacks authority to determine the product being sold.
Preserve country differences that serve a purpose
Standardization is useful when the variation is accidental. It becomes risky when it removes a necessary local distinction. Separate global attributes, entity-specific operating attributes and historical source references in the proposed target design.
NetSuite OneWorld supports multiple subsidiaries in one account. That broad capability does not mean every customer, vendor or item should be made globally identical. Available sharing and transaction behavior must be checked against the enabled features, record type and required entity relationships.
Singapore invoice requirements provide a practical reason to validate identity carefully. IRAS identifies supplier and customer details among the information required on a regular tax invoice. The applicable document type and transaction treatment still need finance review; a brand-level label cannot be assumed sufficient for every document. The migration acceptance test should inspect the actual resulting document for the relevant scenario.
Keep the broader operating model in CuriousRubik's guide to NetSuite master-data governance. The migration-specific task here is to close ambiguous identity decisions for a defined population before its final transformation.
A filled decision register
The sample register has three outcomes:
- Harbour Retail: preserve the two legal-buyer identities. Evidence is the country-approved buyer documentation and related open orders. Country finance approves identity; regional sales approves the analytical relationship. The target test must show receivables and documents against the intended buyer.
- V100: preserve both suppliers with source-qualified references. Evidence is the separate source-system lineage and contracting parties. Country procurement approves the identities; the migration lead tests that each source bill resolves to the correct supplier.
- Standard carton: hold the match pending product evidence. Operations owns the packaging question. The release condition is an approved unit relationship and a successful representative order-and-fulfilment test, not a completed description field.
Close the pack before the final extract
Choose a decision cutoff that allows approved mappings to be built and tested. After that cutoff, route new changes through a visible amendment process. Otherwise a country steward can correct the source while the migration team loads an earlier interpretation.
Version the decision register with the mapping file. Record which source extract it applies to and how late additions are handled. The control should prove that every approved source key resolves to the intended target and that excluded records remain excluded. A high load-success rate cannot establish those relationships.
Oracle documents that CSV import availability depends on permissions, enabled features and supported record types. The migration lead should therefore demonstrate the chosen customer, supplier and item representations in the intended account before the final load. A merge recommendation is a business decision; the supported implementation route is a separate technical question.
At handover, give the receiving shared-service team the unresolved cases, approved exceptions and source-to-target lookup. That lets someone answer why two similar names remain separate or why one legacy code maps differently by country. The most useful migration outcome is a set of identities that people can defend in a transaction, with local accountability preserved after centralization.
