NetSuite2.com Migration Audit: Parity, Permissions, Cutover

Executive Summary

As of October 15, 2026, NetSuite2.com migration should be assessed as an evidence and remediation exercise. Oracle states that NetSuite.com is unavailable when an account upgrades to NetSuite 2026.1 and that legacy-source queries will not work. Its current schema documentation also acknowledges temporary exceptions for some users, so account-level access must be established rather than inferred from the calendar. The decision is whether every required business output has an authorized, explainable replacement, including outputs that already refresh successfully. ^{[1] [2]}

A migration audit must establish semantic parity, meaning equivalent business meaning, rather than matching Structured Query Language (SQL) text. Oracle's mapping page identifies a spreadsheet updated June 19, 2026, warns that its coverage is incomplete, and explains that mappings are not always one-to-one. ^[3] Authentication also needs role-specific treatment: the Data Warehouse Integrator (DWI) documentation requires token-based authentication (TBA). A generally preferred authentication method cannot substitute for the requirements of the actual role and connector. ^[4]

The recommended evidence chain connects each legacy query to its replacement, execution identity, comparison population, control results, downstream consumer, and approval. Reconciliation should combine row counts, financial totals, duplicate checks, null rates, and permitted-value tests. Great Expectations documents exact row-count checks; dbt documents uniqueness, nullability, accepted-value, and relationship tests. Decimal arithmetic is appropriate where strict accounting equality is required. None of these controls alone establishes complete parity. ^{[5] [6] [7]}

Cutover acceptance should require the production identity to return the intended rows and exclude unauthorized rows, with accepted differences recorded explicitly. Least privilege means access sufficient for assigned tasks; a wider-access test identity is therefore a diagnostic aid, not the acceptance identity. Business intelligence (BI) validation must also reach the displayed report: Power BI distinguishes data refresh from query-cache refresh, and Tableau documents separate refresh schedules for embedded extracts. Where the legacy source is unavailable, archived extracts and approved historical outputs become comparison evidence; the audit must disclose their timing and completeness limits. ^{[8] [9] [10]}

Introduction and Background

A warehouse connection can succeed while the report it feeds changes meaning. That makes a NetSuite.com to NetSuite2.com migration an unsuitable candidate for sign-off based only on connectivity or a completed job. Fivetran explicitly says that migration requires query changes and documents differences in custom-field naming. The meaningful unit of completion is the business output produced through the complete dependency chain. ^[11]

The audit boundary must distinguish the source, connector, transformation, semantic model, and delivered report. CData, for example, distinguishes its affected SuiteQL-schema implementations from its unaffected SuiteTalk-schema implementations. Its object mappings describe its own abstraction. Applying a connector-specific instruction to every NetSuite integration would make the inventory less reliable before testing even begins. ^[12]

This report addresses BI and data-platform owners, controllers, auditors, Connect administrators, and implementation partners. It proposes a reproducible acceptance method, rather than claiming account-level test results. No NetSuite account was supplied or executed against for this report. Every example and threshold below is either a documented product behavior or an explicitly proposed audit control. The implementation team must record account type, enabled features, role, channel, and execution date before drawing conclusions about its own environment.

For consultancy-led work, including an engagement commissioned from Houseblend, the deliverable should be the same reviewable evidence pack an internal team would produce. The controller defines financial meaning; the data owner defines consumer obligations; the administrator establishes authorized access. Least privilege remains the appropriate boundary for the execution identity, regardless of who performs the remediation. ^[13]

The central question is practical: can an independent reviewer reproduce why the replacement output is acceptable? A dashboard screenshot, an undocumented SQL rewrite, or an unrestricted export cannot answer it alone. OpenLineage's distinction between declared lineage and lineage observed during a run provides a useful model: intended dependencies and observed executions should both be recorded. This does not imply automatic NetSuite coverage by OpenLineage. ^[14]

Key Changes

Removal changes the available baseline

Oracle's removal notice states that legacy-source queries stop working after the account's upgrade to NetSuite 2026.1. The schema page separately notes temporary exceptions. These statements support a post-removal audit, with explicit account verification, rather than another universal future-deadline warning. An exception should be documented as an account condition, not assumed to provide a durable comparison environment. ^{[1] [2]}

Where legacy access has ended, use retained query results, approved close outputs, archived extracts, and transformation versions as evidence. Record whether they represent the same population and effective time as the replacement. AWS Database Migration Service (DMS) documents a row-comparison approach and notes that continuously changing rows cannot be validated in that process. This supports the importance of comparison timing; it does not establish that AWS DMS validates NetSuite directly. ^[15]

Mapping changes business meaning

The official mapping is a starting point rather than a completeness certificate: Oracle documents incomplete record and field coverage, non-one-to-one mappings, and changed timestamp behavior. Save the mapping artifact used by the project, its retrieval date, and unresolved exceptions. Do not infer that an unmapped legacy field has disappeared, or that a similarly named replacement preserves its meaning. ^[3]

A concrete example is grossAmt. Oracle documents a change from an amount excluding tax in the legacy source to an amount including applicable tax in the replacement, with the amount field used for the excluding-tax value. A total can therefore reconcile only after the financial definition is made explicit. Classify such a difference as a mapping or definition issue before deciding whether it is acceptable. ^[16]

Connector abstractions add another layer. CData's guidance, for example, describes querying invoice information through its Transactions abstraction and identifies a TimeEntry-to-TimeBill change. These are reasons to retain the connector schema and query channel in the exception register, not instructions to copy those identifiers into raw Connect queries. ^[12]

Enumerations and functions require explicit review

Oracle documents numeric enumeration changes for system-note fields and differences in system-note coverage. A legacy text filter can therefore require a translation and a coverage decision, even when the replacement query returns rows. Preserve the original value, the replacement code, the approved label, and the business use of the filter. ^[17]

Function migration also needs an inventory. Oracle publishes supported SuiteQL functions and a nonexhaustive unsupported-function list. Review each function and expression against that documentation, then test the complete expression in the intended channel. This report deliberately excludes a generic SQL tutorial: the audit needs a record of changed behavior and verified outputs. ^[18]

Implementation Considerations and Process Changes

Confirm the legacy footprint

Start with connection definitions and observed activity, then expand to consumers. Oracle documents a Connect Login Audit dataset using Data Source, Date, and Email Address, filtered to NetSuite.com, to identify legacy-source users. Treat it as evidence of connection activity, not proof that every query, workbook, or dormant consumer has been found. ^[19]

Power BI lineage shows artifact dependencies and last refresh information, but Microsoft qualifies lineage for manually created Mashup connections. Combine the tool's view with scheduler definitions, transformation repositories, report ownership, and historical delivery records. Absence from a lineage screen should not close an inventory item by itself. ^[20]

Table 1 is a proposed combined query inventory and mapping-exception register. It records the information needed to distinguish source semantics from pipeline behavior. Fivetran's migration documentation and Boomi's validation guidance support reviewing both queries and downstream calculations. ^{[11] [21]}

The register should remain open until the consumer is accounted for, even if the rewritten query passes. OpenLineage's declared-versus-observed distinction is useful here: ownership of an intended dependency does not establish that the expected production run actually occurred. Attach a run identifier and observed output to the inventory entry. ^[14]

Change the connection without losing provenance

Oracle's migration instructions require changing the data-source attribute and converting SQL queries to SuiteQL. Version the connection and query for NetSuite2.com SuiteQL migration. The connection change and the semantic rewrite should be independently reviewable, because either can explain an output difference. ^[22]

Capture connector-specific settings before replacing a job. Qlik documents that Stitch's TBA setting cannot be changed once the integration has performed an extraction, requiring a new integration for that change. Matillion documents a component that reloads its target on execution and can recreate or truncate it under its load configuration. These are workflow-specific behaviors to inspect, not universal Connect rules. ^{[23] [24]}

The SuiteAnalytics Connect migration checklist should make acceptance reviewable:

• Assign ownership: identify the technical owner and business approver for every retained output.
• Freeze definitions: preserve the original SQL, parameters, filters, and transformation version.
• Capture settings: retain connection and load settings without storing secrets in the evidence pack.
• Map exceptions: document unavailable, renamed, split, joined, or redefined fields.
• Retain runs: attach execution identifiers, effective periods, and comparison artifacts.
• Close consumers: require evidence from the report or export that the owner actually uses.

Boomi recommends revalidating transformations, joins, and calculated fields, and its migration guidance recommends a one-time full reload. Apply that advice to the relevant connector workflow after assessing its configuration and comparison baseline; a reload is not, by itself, evidence that the final business output agrees. ^[21]

Permissions and Role Validation

Test the intended identity

NetSuite2.com permissions are part of data correctness. Airbyte explicitly documents that the role controls connector visibility. A broad-access extraction used during development can therefore be a useful diagnostic comparison while remaining unsuitable as evidence of the production role's authorized output. Least-privilege guidance supports testing the actual identity and its required scope. ^{[25] [8]}

Oracle generally prefers OAuth 2.0 for Connect, but its DWI role documentation requires TBA. The DWI page also says Global Permissions take precedence over that role and that credit card information is inaccessible. Maintain the role-specific requirement in the permission matrix rather than assuming that a general authentication recommendation establishes compatibility. ^{[26] [4]}

The Administrator role has an OAuth-specific access exception documented by Oracle. Record the exact identity used for diagnostic exports; do not write simply “admin test passed.” A comparison is meaningful only when the reviewer can distinguish a broad diagnostic result from the intended service identity's acceptance result. ^[27]

Authorization testing should include expected denials as well as expected access. OWASP recommends minimum necessary privileges and permission-enforcement testing, while also warning against assuming third-party configuration behaves as intended. The following matrix dimensions are proposed account tests, not blanket claims about how every NetSuite custom role behaves. ^[13]

• Allowed scope: prove access to the required subsidiaries, records, fields, and reporting periods.
• Excluded scope: demonstrate that deliberately out-of-scope records remain unavailable.
• Identity pair: compare the diagnostic identity with the actual unattended-job identity.
• Role configuration: retain role identifiers, relevant permissions, and global-permission settings.
• Channel: distinguish direct Connect execution from a connector or reporting abstraction.
• Environment: record production, sandbox, or preview status and enabled features.
• Authentication: record the mechanism and connector support without retaining token values.
• Reproduction: save the query version, parameters, effective time, and execution date.

Separate visibility from coverage

System notes provide a specific visibility test. Oracle says users without the Administrator role or System Notes for Analytics and REST permission see only changes they made themselves. A lower count under such an identity should first be assessed against that documented access rule. It is not sufficient to compare unrestricted and restricted counts and label the difference a query defect. ^[17]

Messages have a distinct permission: Oracle says that without Administrator or Messages for Analytics and REST, results are limited to messages authored or received by the user. Test the business requirement for this population separately from transaction totals. Permission parity does not require reproducing inappropriate historical access. ^[28]

Also examine downstream access. Tableau documents that embedded credentials can allow workbook users to see data regardless of their own Connect capability for the published data source, and that Download Full Data permits access to underlying data. Source-role testing therefore cannot establish the permissions of every exported or published result. ^[29]

Time Semantics and Incremental Completeness

Normalize time without erasing meaning

Oracle distinguishes legacy created and lastmodified timestamps returned in Greenwich Mean Time (GMT) from replacement timestamps using user or company preference time zones. Record both preferences and the destination interpretation before choosing a normalization. A changed displayed hour and a changed underlying instant are different audit findings. ^[3]

Python's documentation distinguishes timezone-aware from naive date-time values. Snowflake separately documents that its local-time-zone timestamp stores Coordinated Universal Time (UTC) values with session-time-zone operations, while its no-time-zone timestamp performs operations without timezone consideration. These are downstream semantics to inspect, not a recommendation to select a particular warehouse. ^{[30] [31]}

• Boundary records: include midnight, period-end, and daylight-saving transitions where applicable.
• Raw values: preserve source text or typed values before transformation.
• Zone provenance: record user, company, session, and destination settings that affect interpretation.
• Predicate meaning: document whether filters use business dates or absolute instants.
• Incremental overlap: test boundary inclusion, late changes, and repeated extraction behavior.
• Enum translation: test codes, labels, unknown values, and retained historical categories.

Use aware instants for instant comparisons and preserve business dates as dates when that is their meaning. A naive date-time object does not identify an unambiguous position relative to other date-times; assigning a zone after extraction therefore requires an explicit, reviewed assumption. Retain the original value so the assumption can be revisited. ^[30]

Test full refresh and incremental behavior separately

A replacement can match after a full load and diverge later. Fivetran documents incremental eligibility based on a numeric primary key and supported last-modified column, and notes that automatically calculated changes may not be captured when the source timestamp does not change. Record the extraction mode and the fields that drive change detection for each relevant table. ^[32]

Airbyte documents full-refresh and cursor-based incremental modes. Matillion's component documentation describes reload behavior. These different models require different expectations for repeated runs, cursor boundaries, updates, and retained history. Compare the actual implementation, rather than importing the behavior of another vendor's connector into the acceptance criteria. ^{[25] [24]}

The proposed incremental test set should include:

• New records: establish that an eligible new record reaches its consumer.
• Changed records: compare changes to extracted fields and calculated outputs.
• Boundary timestamps: verify the precise inclusion rule around the extraction watermark.
• Repeated runs: identify whether reruns replace, append, or deduplicate results.
• Removed records: document how the configured pipeline detects or handles removal.
• Full-load recovery: prove the approved reconstruction procedure against a retained baseline.

Stitch's documented append behavior and Fivetran's documented incremental restrictions illustrate why a generic “incremental passed” checkbox is inadequate. Save the test input, observed change, selected load mode, and destination result. Where a table's extraction strategy differs, maintain a separate acceptance record. ^{[33] [32]}

Query Parity and Downstream Validation

Establish grain before comparing totals

NetSuite2.com query parity begins with the intended grain: what a row represents and which columns identify it. dbt documents uniqueness, nullability, accepted-value, and relationship checks. Its relationships test excludes nulls, so a separate nullability control is needed when a missing parent reference must fail. Adopt the checks appropriate to the business definition rather than treating one successful test as complete coverage. ^[6]

Do not let a set comparison hide duplicate differences. PostgreSQL documents that EXCEPT eliminates duplicates unless EXCEPT ALL is used, and requires compatible result columns. If this approach is used in the comparison environment, test both directions and preserve multiplicity where it matters. This is a downstream comparison technique, not a claim that PostgreSQL syntax executes inside SuiteAnalytics Connect. ^[34]

Connector load behavior can change the comparison population. Stitch documents appending new record versions where a destination is append-only or a table lacks primary keys. Boomi's data-flow configuration can filter duplicates before writing. The auditor must therefore decide whether to compare raw versions, current-state records, or business events before interpreting a destination row count. ^{[33] [35]}

Follow the result into the report

Power BI refresh history distinguishes data refresh from query-cache refresh and can report completion with warnings. Review the history details, calculation results, displayed filters, and data freshness. Successful data extraction does not establish that the consumer sees the expected model or cached result. ^[9]

Tableau documents that embedded extracts may be historical snapshots and need their own workbook refresh schedules to remain current. It also separates data-source authentication from the user's Tableau sign-in. Inspect the published connection, refresh identity, extract date, and effective viewer access before asking the owner to approve the displayed figures. ^{[10] [36]}

• Semantic model: verify measures, joins, labels, and calculated fields.
• Refresh chain: reconcile source-run completion with model and report refresh completion.
• Presentation: inspect filters, period labels, drill paths, and blank results.
• Delivery: test the scheduled export or workbook that the owner actually receives.
• Access: test the permitted viewer and any underlying-data download capability.
• Approval: retain the consumer's decision with the exact output version reviewed.

The approval must identify its scope. Microsoft lineage can assist dependency discovery, while Tableau's underlying-data capability illustrates a separate access surface. Neither should be treated as proof that every downstream consumer was discovered or authorized. Capture the observed route from source result to delivered artifact. ^{[20] [29]}

Cutover Evidence and Decommissioning

Keep evidence parallel even without a live legacy source

Parallel evidence can mean a preserved historical baseline compared with the replacement, not simultaneous access to both sources. Identify which input populations can actually be aligned. AWS DMS's documented difficulty validating continuously changing rows illustrates the timing issue, while Boomi's migration guidance explicitly calls for row-count, aggregate, and business-metric comparisons. Neither establishes that two unaligned extraction times should agree. ^{[15] [21]}

Record differences as explained and approved, awaiting correction, or unresolved. Approval should state the business interpretation and downstream consequence, rather than merely accepting a numerical gap. A changed null population, for example, requires a separate decision from a changed total; Great Expectations documents controls specifically for missingness. ^[37]

Table 2 is a proposed NetSuite2.com cutover checklist and consumer sign-off evidence pack. It connects validation categories to accountable decisions. OWASP's configuration-testing guidance and Microsoft's refresh documentation support testing both access and execution behavior before closure. ^{[13] [9]}

Each row closes a different question. In Tableau, embedded credentials and download capabilities can affect who sees the output, while refresh schedules determine whether the displayed extract is current. A source-level control total should therefore never substitute for consumer-level authorization and freshness evidence. ^{[36] [29] [10]}

Retire only the dependencies that have been accounted for

Before disabling a credential, identify other integrations that use the identity or token. Tableau's separation of source authentication from platform sign-in is one reason to inspect stored connection credentials rather than only user access lists. Microsoft likewise documents endpoints, authentication mode, and credentials as part of a gateway data-source definition. Retire the scoped dependency after the owners have accepted its replacement. ^{[36] [9]}

For the recommended retirement record:

• Scope: identify the exact connection, job, identity, and dependent consumers being retired.
• Evidence: retain approved comparisons, exceptions, source documentation, and query versions.
• Credentials: record revocation or retained-use decisions without copying secret values.
• Monitoring: track freshness, refresh warnings, control deviations, and missing deliveries.
• Recovery: retain the approved replacement reconstruction procedure and ownership.
• Closure: record who accepted the outputs and which limitations remain.

Monitoring must inspect the reporting tool's actual behavior. Tableau Cloud documents suspension of directly run refresh schedules after five consecutive failures, and notification details include the last successful refresh. Power BI can complete data refresh while query-cache refresh fails. These are specific operational signals to incorporate where those products are used. ^{[38] [9]}

Data Analysis and Evidence

The quantitative core of NetSuite2.com migration validation is a control design, not a claimed benchmark. No account-level measurements were performed. Great Expectations documents exact row-count and bounded non-null-proportion checks; its distribution guidance supports combining statistics rather than relying on one measure. Use those categories to define a baseline before examining differences. ^{[5] [37] [39]}

For each agreed partition, calculate signed row-count difference as replacement count minus baseline count. Where the baseline is nonzero, calculate the absolute difference divided by the baseline for a relative gap. Preserve the sign separately. A zero baseline needs an absolute difference and explicit review, rather than division by zero. Exact-count expectations provide a practical assertion when the populations are intended to match. ^[5]

For amounts, compare decimal totals at the agreed currency, precision, accounting basis, and grain. Python's decimal documentation explains exact decimal representation and its relevance to accounting equality. Great Expectations documents bounded column sums. Avoid mixing currencies or changing rounding rules merely to make a control pass. ^{[7] [39]}

Table 3 is a Hypothetical Example, with invented inputs and calculations performed for this report. It illustrates how proposed controls expose different questions; it is not a measured NetSuite result or an external benchmark. The control types correspond to documented count, nullability, uniqueness, and distribution checks. ^{[5] [37] [6] [39]}

The different row and amount gaps require partition-level examination; they do not identify a cause. The null-rate change is approximately 0.4975 percentage points, which is distinct from a relative percentage change. These are arithmetic results from the invented inputs. A useful next step is to examine affected keys and partitions, using duplicate-aware comparisons where appropriate. PostgreSQL's distinction between EXCEPT and EXCEPT ALL matters to that choice. ^[34]

Recommended control evidence includes:

• Counts: compare total and partition counts, recording the population definition.
• Amounts: compare totals by relevant period, currency, subsidiary, and accounting basis.
• Null rates: calculate null count divided by row count for each critical field.
• Relationships: check orphan references and test nulls separately where required.
• Enums: compare approved values, unknown values, and the distribution of mapped labels.
• Duplicates: compare multiplicity at the agreed grain before and after deduplication.

dbt's accepted-value and relationship tests and Great Expectations' missingness checks provide implementable patterns for these controls. The report recommends that tolerances be approved before reviewing results, with exact equality where the underlying definition demands it. There is no universal percentage in this report that authorizes a financial difference. ^{[6] [37]}

Implications and Future Directions

The durable outcome is a governed data contract: an identified population, approved definitions, authorized execution identity, reproducible comparison, and accountable consumer. Connector configuration remains part of that contract. Boomi documents automatic inclusion of new columns and configurable duplicate filtering; such settings should trigger review when they change the compared shape or grain. ^[35]

Authentication capability also changes by connector and release. Rivery's January sources update, published in February 2026, announced OAuth 2.0 for NetSuite Analytics. Airbyte documents several authentication mechanisms, while Matillion describes an OAuth-only replacement component. These vendor-specific statements should be checked against the deployed version and actual role rather than generalized into one rule for the platform. ^{[40] [25] [24]}

Transformation packages need equivalent attention. Fivetran's migration guidance specifies a data-model variable for its NetSuite2.com package version. A source migration can therefore require a change in downstream model configuration as well as SQL. Retain package versions and configuration with the comparison results so that a later rebuild can be interpreted. ^[11]

Ongoing evidence can be lighter than the initial audit but should preserve its definitions. dbt's tests offer repeatable structural and domain checks; Great Expectations' guidance supports monitoring multiple distribution measures. Keep those checks aligned with the controller's approved meaning instead of letting an implementation default become the acceptance standard. ^{[6] [39]}

Finally, preserve the separation between declared dependencies and observed runs. OpenLineage describes that distinction, and Microsoft's lineage view provides useful refresh and dependency context with documented limits. Future changes to features, roles, mappings, connectors, and report models should reopen the affected controls. An accepted migration is evidence about a recorded configuration and population, not an unrestricted guarantee about future outputs. ^{[14] [20]}

Conclusion

A completed NetSuite2.com migration audit should answer whether every required legacy output has an authorized replacement, whether its business meaning is preserved, and whether accepted differences can be reproduced. The evidence should follow the result from query and execution identity through transformation, refresh, presentation, and delivery. Boomi's guidance to compare business metrics as well as counts captures why the output matters more than a successful connection alone. ^[21]

The practical sequence is to inventory consumers, preserve the comparison baseline, map exceptions, rewrite and version the queries, test the intended role, normalize documented time semantics, reconcile controls, obtain consumer sign-off, and retire accounted-for dependencies. Use multiple checks: exact counts, valid keys, missingness, amount totals, and approved categories answer different questions. Great Expectations' distribution guidance explicitly cautions against depending on a single statistic. ^[39]

Where historical evidence is incomplete, the sign-off should say which outputs and periods were tested and what remains uncertain. Where access legitimately narrows, document the authorized population rather than forcing a match to a broader extract. Least privilege remains the boundary for the production identity. The resulting evidence pack should let a reviewer understand what changed, why the replacement is acceptable, and which future configuration changes require retesting. ^[8]