Configuration Is Not Data

A complete data export gives you your records. It does not give you the thing that took longest to build.

Reviewed August 9, 2026.

What configuration means here

Everything you set up inside the tool that is not a record.

Custom fields and objects. The shape you gave the product to fit your process. For a related operational perspective, Monitask also publishes a reference on task switching cost.

Workflows and automations. Rules that fire on events, approvals, notifications, escalations.

Views, filters and saved reports. The way people actually use the thing day to day.

For broader context, see European Data Protection Board.

Permission structures. Roles, groups, who sees what.

Templates. Project templates, document templates, email templates.

And integrations, which are their own subject and their own lock.

Why it is worth more than the records

Records took time to accumulate. Configuration took time to design.

The records are the output of the business; they would exist in some form regardless of the tool. The configuration is the encoding of decisions — how approvals work, what stages a project has, who can see salary fields — and those decisions were argued about, tested and revised.

A migration that carries the records and not the configuration has moved the easy half. The other half is rebuilt from memory, by people who did not make the original decisions, under time pressure.

The ownership question

Worth checking in the contract, because it is not obvious.

Some agreements assign ownership of customer-created configurations, workflows and integrations to the vendor.

That is a clause, not a default, and it appears in more contracts than people expect. It matters if you built something substantial on the platform.

Ask: who owns the configurations, templates and integrations I create? And read the intellectual property section rather than accepting a verbal answer.

What to do while you are still there

Document the configuration outside the tool.

Not a backup — a description. What the workflows do and why, in a document somebody who was not there can read.

Screenshot the permission matrix.

Export report definitions where the product allows it, and where it does not, write down what each report shows and who uses it.

Keep the decision record. Why approvals have three stages, why that field is mandatory. In a migration this is the difference between rebuilding and re-deciding, and re-deciding takes months.

An afternoon a year, and it is the only part of a future migration you can do in advance.

The realistic expectation

Assume configuration does not transfer.

Between products it almost never does; even between versions of the same product it frequently does not.

Which means a migration budget has two parts: moving data, which is mechanical, and rebuilding configuration, which is a project.

Estimating only the first is how migrations overrun, and it is the estimate every vendor's onboarding team will help you make.

The short version

• Configuration is custom fields, workflows, views, saved reports, permissions, templates and integrations — everything you set up that is not a record
• Records accumulate; configuration encodes decisions that were argued about and revised, which makes it the more expensive half
• Some agreements assign ownership of customer-created configurations to the vendor, which is a clause rather than a default — read the IP section
• Document the configuration outside the tool: what workflows do and why, the permission matrix, report definitions, and the decision record
• Assume configuration does not transfer between products, and frequently not between versions
• A migration budget has two parts, and estimating only the data half is how migrations overrun