How to Check Farm Software Data Export Before You Subscribe

Before subscribing to farm software, test whether your team can obtain records in a form it can actually use outside the service. A visible dashboard, polished report or integration claim is not the same thing as a usable export.

The practical question is narrower: if you need to review, archive, share or move selected records, can the provider supply files that retain the information and context needed for that task?

Ask for a sample export based on a small, realistic test set. Then open it with the tools your team expects to use and compare it against a written list of requirements. This does not prove that every future export or migration will work. It does provide a bounded check of the provider’s current example, export route and operating process before procurement is complete.

Start with the records your team must reuse

Treat export checking as an operational handover exercise, not a feature-box comparison. Begin with the decisions and handovers that require records outside the platform.

For example, your team may need to:

• retain operation logs for internal review;
• provide selected records to an authorised adviser or buyer;
• combine field measurements with another system;
• archive documents and attachments at the end of a season;
• prepare for a change of staff, contractor or software provider; or
• inspect historical corrections when a record is questioned later.

Write down the scope before asking for files. A useful request identifies the organisation or account involved, the relevant sites or production areas, the record types, the time range and the intended reuse. The World Farm Tech portability audit guide similarly frames an export request around scope, source version, expected record categories and delivery details.

This scope does not need to be long. It does need to be specific enough that a provider cannot satisfy it with a single summary report when your team needs underlying records.

A working requirement might read: “We need selected operation records, measurements, input records and associated attachments for one site over a defined test period, with identifiers and dates sufficient to relate them to each other.” That is more useful than asking whether the service “supports data export.”

Keep examples non-sensitive during evaluation. Use test entries rather than real employee, customer or commercially sensitive records where possible.

Ask what export route and formats are actually available

“Export available” can describe several very different arrangements. Ask the provider which route applies to the records in your scope.

The format matters, but no single format is automatically sufficient. CSV files can be useful for tabular records, but they may not carry attached documents, map layers or relationships between records. A spreadsheet file may be convenient for a reviewer but unsuitable for automated import. A PDF may preserve a human-readable report while being a poor substitute for structured records. Geospatial files may be relevant where location data is essential, but the receiving tool still needs to interpret the coordinate reference, attributes and identifiers correctly.

An NFF Farm Data Code audit report illustrates why it is worth asking about the route as well as the format: it describes exports through reporting functions and, separately, a fuller extract requested through support. That example should not be treated as evidence that another provider offers the same options.

Also distinguish receiving a file from using it successfully. As InduWire notes in its discussion of digital farming platform compatibility, a system may receive data without necessarily interpreting it correctly, preserving its meaning or returning usable output. File availability is therefore a starting point for review, not a conclusion about interoperability.

Ask the provider:

• Which export formats apply to each record category?
• Can an authorised user download files directly, or must support prepare them?
• Are attachments delivered as separate files, links or embedded content?
• Does the export include machine-readable records, human-readable reports, or both?
• Are map, equipment or sensor records handled differently from operation records?
• Can the same export be requested again after new records are added?

Check the fields, units and links inside a sample export

A file can open without errors and still be inadequate for your workflow. The key review is whether the exported content keeps enough context to be understood later.

Build a small test set that reflects the relationships you expect to use. A useful hypothetical set could contain:

• one operation record;
• one measurement with a stated unit;
• one input record;
• one attachment; and
• one correction to an earlier entry.

This approach is consistent with the practical test-set idea outlined by Soil Practice. It is not a compatibility test in itself; your team must define the records and links that matter in its own workflow.

Open the export in the intended destination tool. That may be a spreadsheet, records archive, mapping application or another farm system. Then inspect a few records line by line rather than relying only on a totals page.

ACA practical export review checklist

For each relevant record type, check whether the sample preserves:

• a stable record identifier or reference;
• operation date and, where relevant, time;
• site, field, block, zone or asset reference;
• operation type and status;
• measurements with their units;
• input name, quantity and unit where those fields are needed;
• links to related records, such as a measurement linked to a location or operation;
• attachment names and a usable way to obtain the files;
• location information, coordinate reference and map attributes where applicable; and
• readable labels rather than unexplained internal codes alone.

Do not assume a map that looks correct is complete. Identifiers, application units, coordinate references and attributes can be lost, renamed or interpreted differently between systems. The purpose of the check is not to demand every possible field. It is to identify which missing field, relationship or unit would prevent a real handover or later review.

Record gaps precisely. “Export incomplete” is difficult for a provider to investigate. “The measurement file includes a value but not its unit” or “the attachment listing has file names but no files or retrieval links” is clearer and easier to compare against a response.

Test time range, history and record changes

Current values may be enough for a simple operational report. They may not be enough where your team needs to understand how a record arrived at its present form.

Define the time range in the sample request. If you care about a growing period, an entire season or a transition period between two systems, say so. Ask whether the export is a current snapshot, a historical extract, or a combination of both.

Where relevant to your workflow, include a corrected test record. For example, enter a measurement, correct it later and ask how both the current value and the correction are represented in the export. Your review can then ask practical questions:

• Does the export show only the latest value?
• Is the original entry retained or identifiable?
• Is there a modified date or status?
• Can the team tell that a correction occurred?
• Are deleted, archived or voided records distinguishable from records that never existed?

Not every farm needs a detailed change history for every record. The requirement depends on the workflow, the people receiving records and the purpose of retention. The important point is to decide this before interpreting an export. The World Farm Tech guide highlights the value of specifying time range, history and audit records as part of the request, rather than discovering these questions after the files arrive.

Ask the provider to explain ambiguous fields in writing. A column called “updated” may mean the last software sync, the last edit by a user, or the date a report was generated. Labels alone do not establish meaning.

Confirm who can request, download and receive the files

An export capability is only useful if the right person can use it when needed. Map the practical access path before subscribing.

Identify the organisations, accounts and roles involved. This may include the farm business, managers, staff, advisers, contractors, dealer support or a service provider responsible for administration. The World Farm Tech offboarding review is useful context for this mapping exercise because it separates people, accounts, delegated authority, services and support relationships.

For the proposed service, ask:

• Which role can request or download an export?
• Can an administrator delegate this task to another authorised person?
• Does a departing staff member hold a necessary account or authentication method?
• Is support involved in supplying fuller extracts?
• How are files delivered: download link, account message, email or another method?
• Can the recipient access attachments and supporting files through the same process?
• What information must accompany a request to show the requester is authorised?

Keep a simple access record with the procurement documents: requester role, approving role, export route, delivery method and provider contact point. This is an operating control, not a legal conclusion about data ownership or rights. Service terms and applicable local requirements may affect access arrangements, so review your own agreement where that matters to the team.

Use a pass-or-clarify export check before committing

A sample export is a limited check, not a promise of complete migration, future availability or continuous synchronisation. It can still reveal important questions early, when the team can compare providers or adjust implementation plans.

Use this pass-or-clarify process:

1. Define the use case. State why the records may be reused and which categories, relationships and dates are required.
2. Create a small test set. Use clearly labelled, non-sensitive entries that include one relationship, one measurement with units, an attachment and a correction where relevant.
3. Request the actual export route. Do not rely on a screen demonstration if your likely process requires a support request or an integration.
4. Open the files in the intended tool. Check that the team can read the files and locate supporting material without relying on undocumented steps.
5. Compare contents against the written requirement. Mark each item as passed, missing, unclear or not tested.
6. Ask for clarification in writing. Record explanations of field names, history, attachments, refresh options and access roles.
7. Retain the evidence. Keep the sample files, request wording, screenshots where useful and comparison notes with the procurement record.

If your team expects records to be refreshed regularly, include that workflow in the discussion. Research on agricultural data sharing from the Open Ag Data Alliance framework highlights the operational burden that can arise when people repeatedly move files between systems. A one-time download may be adequate for an archive; it may be impractical for a weekly planning process.

The bounded next step is straightforward: prepare a one-page export requirement, request a realistic sample and retain the result alongside the subscription decision. If a provider cannot clarify an essential field, relationship, history requirement or access step, record that gap rather than assuming it will be resolved after implementation.

Questions teams often ask

What should be included in a farm software sample export?

Include the record types your team expects to reuse, along with a realistic time range. A small test set can include an operation, a measurement with units, an input record, an attachment and a corrected record. Check identifiers, dates, locations, units, related-record links and attachment access.

Is a CSV export enough to move farm records to another system?

Sometimes, for a defined set of tabular records. It may not be enough for attachments, maps, relationships, history or fields that require a particular schema. Open the CSV in the intended destination tool and compare its contents with your stated requirements before treating it as sufficient.

Can a PDF report be used as a farm data export?

A PDF can be useful for reading, sharing or archiving a fixed report. It is usually less suitable where the receiving team needs to filter, analyse, import or relate individual records. Whether it is adequate depends on the intended use.

What should we record when a provider supplies a sample export?

Keep the request scope, date received, files and formats supplied, account role used, delivery route, fields checked, missing or unclear items, and the provider’s written explanations. This gives procurement, operations and future administrators a common record of what was tested.