NetSuite OpenAir data export and archiving

Why export OpenAir data before a change#

An OpenAir data export matters most when access to the system is about to change: a move to another PSA or ERP, an acquisition that brings a group system, a wind-down or an exit process. Once the subscription ends, the firm's history of how it scoped, staffed and billed its work depends on what was taken out beforehand.

The new system rarely needs that history. Most firms load open projects, active staff and current rates, then leave closed engagements behind. The archive is what preserves the rest, so treat it as a deliverable with an owner rather than a by-product of the migration.

One well-built copy serves several later uses: answering a client billing dispute, supporting an audit of revenue, giving an acquirer diligence evidence, analyzing pricing and utilization, or assessing whether the records can be licensed.

Which OpenAir records belong in the archive#

The OpenAir records that belong in an archive are the transactional records plus the reference data needed to read them. Without the reference tables, a timesheet row is a string of IDs with no project, person or customer attached.

Confirm the list against your own account. Firms configure OpenAir differently, and custom fields often hold the most firm-specific information, such as engagement type, practice area or delivery model.

Contract terms to read before scheduling the export#

The subscription agreement and order forms decide how much room the firm has to get its data out, so read them before setting a cutover date. Look for renewal and notice dates, any clause on data retrieval after termination, the formats the vendor commits to provide, and whether vendor-assisted extraction is included or quoted separately.

Confirm who holds administrator rights on your side. Complete exports usually need an administrator role, and an export that depends on one person's login is fragile if that person leaves during the transition. Where the agreement is silent on access after termination, assume access ends on the termination date and schedule the final extract with room to spare.

Step by step: exporting OpenAir data#

Exporting OpenAir data works best as a sequence, with reference data first and a final delta extract last. Check Oracle's current OpenAir documentation and your administrator for the export routes your account supports, which can include saved report exports and programmatic access.

Keep an export log as you go: who ran each extract, when, through which route, with which filters, and how many records it produced. The log is what lets a later reader trust the archive without access to the source system.

• 1Name an owner for the export and freeze configuration changes such as new custom fields or renamed project stages.
• 2List every record type and custom field in use, including fields that only one practice fills in.
• 3Export reference tables first, with filters set to include inactive users, closed projects and archived customers.
• 4Export each transactional record type at entry level, keeping internal IDs and the keys that point to parent records.
• 5Export approval history, rejection notes and status changes wherever your account retains them.
• 6Download attachments such as receipts and signed documents, and name or index each file by the expense report or project it belongs to.
• 7Reconcile against OpenAir: total hours by project and period, invoice totals and record counts by type.
• 8Take a final delta extract after the last timesheet period and billing cycle close.

Why summary reports are not an archive#

Summary reports are built to answer current questions, not to preserve history, so they make a weak archive. A utilization report aggregates hours, a project list shows today's names and status, and both apply filters the person running them may not notice.

Three losses are common. Default filters can show only active users and open projects, so departed consultants and closed engagements disappear. Aggregated rows drop the entry notes that explain why time was written off or moved. Names replace internal IDs, so records cannot be rejoined once a client or project has been renamed.

Reports still have a role. A fixed copy of key reports, run on the export date, is useful evidence for reconciling the raw tables and for answering quick questions without querying the archive.

Choosing an archive format that stays readable#

An archive format stays readable when it is open, documented and independent of the software that produced it. Most firms combine a raw data layer with a small set of human-readable views.

Pair the files with a data dictionary that explains every column, code and custom field, plus a short provenance note. The Data & Trust Alliance's Data Provenance Standards group dataset metadata into Source, Provenance and Use, a structure that works well for describing where an export came from and what it may be used for.

Illustrative: an IT advisory firm retires OpenAir after an acquisition#

Illustrative: a fictional IT advisory firm is acquired by a larger group that runs its own PSA and ERP. Group IT plans to end the firm's OpenAir subscription at renewal, and the COO is asked to move open projects across and keep everything else.

The first trial export comes from the standard timesheet report, and reconciliation fails: hours logged by departed consultants are missing because the report filters to active users. The team re-exports time entries at entry level with inactive users included, adds rejection notes and booking history, and downloads expense receipts with a manifest keyed to expense report IDs.

Open projects load into the group system. The full history goes into CSV files and a database copy, with a data dictionary and export log, stored read-only with access limited to finance and the COO. Later, the archive settles a client billing query and supports a pricing review without anyone reopening the vendor relationship.

How SourceX looks at an OpenAir archive#

SourceX looks at an OpenAir archive as a record of how consulting work was planned and delivered: budgets against actual hours by phase, bookings against who actually worked, and approvals and rejections with their notes. Linked to proposals and project reviews, those records show professional judgment in sequence, which is what AI developers look for in operational data.

The work follows the SourceX five-step transaction: Supply, Rights, Preparation, Approval and Delivery. The first fit check runs on a description of the archive alone: the source system, the record families it holds and the span of years covered. Employee names, cost rates and expense details are removed or pseudonymized during Preparation, the firm approves before anything is released, and large archives stay in the firm's own storage. In the SourceX Enterprise Data Value Framework, recency, scale and data cleanliness raise value, while preparation cost and privacy burden reduce net value.