Business system data exports: what to test before choosing a provider

Before choosing a business system, check that you can extract information that lets you continue working. An export button is not enough: you need to know which records are included, whether relationships survive, how attached files are downloaded and how another team interprets the result. Ask the software provider or development team for a small export exercise using demonstration data. Test one business action outside the original system before information accumulates inside it.

What can software buyers learn from the Revit debate?

In September 2022, AEC Magazine published an update from architectural practices that had written to Autodesk. The group described concerns about interoperability and dependence on the RVT format; the article also discussed the cost of retraining teams for another tool. These are historical participants’ views, not our assessment of the product today. Our takeaway for software buyers is that leaving costs include information and working practices, not just the monthly subscription.

That dependence is not necessarily a reason to reject a product. Ready-made software can save substantial development work, while custom development also creates dependencies on data structures and team knowledge. The question is whether the choice is explicit: what can you take with you, what work will make it usable, and what will you have to rebuild? A concrete example provides a better answer than a general statement that the customer owns the information.

What belongs in a useful export?

Choose a central workflow, such as a customer with several orders, each containing attachments and a status. Request a field list and an explanation of the identifiers connecting the records. A customer name is not always a stable identifier: two customers may share a name, or a name may change over time. In the demonstration, check that each order can be assigned to the correct customer without guessing or opening the old interface to fill in missing information.

Remember what surrounds the table. A link to a file inside the provider’s account may stop being useful after the relationship ends, so establish whether you also receive the file itself. Change history, custom fields, dates and time zones may matter to your workflow. Not every system needs to export everything. Each exclusion should be documented and understood by the person responsible for the business operation.

How is a readable file different from portable information?

A CSV file that opens in a spreadsheet is a start, but it does not explain field meaning on its own. A value such as “closed” might mean an order was delivered, cancelled or no longer needs attention. Define a short dictionary of terms and possible values. Pay particular attention to empty fields: do they mean missing information, an action that has not happened or a field that does not apply? The receiving system needs to distinguish those cases.

The Julius website’s content system contains an explicit mapping layer between CMS records and the article structure displayed by the site. It maps Hebrew and English fields, structured content and dates. The publishing tool also reads articles in batches so it does not stop at a partial database listing. These are facts from our implementation; they do not prove that we completed a migration to another provider. The example shows why field meaning and complete retrieval need to be visible before discussing data portability.

How do you run a small migration exercise?

Create a few records in a test environment that represent the work: a normal item, an item with an attachment, an item whose state changed and an item containing Hebrew text. Use synthetic information or data approved for this purpose, rather than real customer records for an informal demonstration. Export the sample and ask someone who did not build the system to explain its contents using only the documentation.

Next, ask that person to complete one action in a destination tool or experimental environment: find all orders belonging to a customer, display a related document or calculate a simple report. Compare record counts and results against the source, recording anything lost or requiring manual repair. This is a proposed exercise, not a promise that every migration can be completed this way. A small sample reveals classes of problems, but it does not prove a large database transfer will meet the allotted time or resource budget.

What should you agree before buying or building?

Agree who can export, how often export is available, whether volume limits apply and what happens when the account closes. If a destination is already known, request an estimate for conversion work and training as well. When comparing proposals, separate the cost of obtaining files from the cost of running the workflow elsewhere. A low export price does not remove the work needed to make the information useful.

Include these requirements in the technology product specification, with a scenario and a result that can be tested. If the product uses AI, separately define what is retained from inputs, outputs and human decisions, and which components need rebuilding with another provider; see our guide to choosing AI developers. For a meeting with the Julius development team, bring a sample report or export without sensitive information. It provides a starting point for testing the cost of moving before committing to a system.