A software subscription earns its place by spreading security work, compliance, maintenance, and product development across a large customer base, a cost a company may not want to carry for work that does not set it apart. The mistake is applying that default to the one or two workflows a customer uses to judge the business.
A renewal review can arrive as two numbers: the annual license total and a custom-build estimate. Both fit in a spreadsheet. Neither number counts the validation rules and approval flows the operations team already maintains inside the product, the spreadsheet kept beside it because the product will not model a split shipment, or the discovery during a migration that the export never carried the link between an order and its signed delivery note.
Where a Subscription Is Still the Right Answer
Payroll, email, accounting, calendaring, video meetings, e-signature, and a standard helpdesk are commodity workflows unless regulated or local requirements change that for a particular business; otherwise what one company needs from them is largely what many other companies need. A vendor funds the compliance updates and the security patching once and spreads the cost across its customers.
Replacing a sound accounting package with a bespoke general ledger commits the company to maintaining a ledger indefinitely, and the market already sells that ledger for a monthly fee.
Which Workflow Would a Competitor Fail to Copy?
The candidates are narrower than a department name. A distributor that quotes unusual product combinations has a pricing rule its salespeople carry in their heads because the CRM cannot express it. A service company that promises delivery dates has a scheduling rule that decides which jobs are allowed to slip. Each of those is specific enough that the people who run it can say whether the product handles it, which is why the conversation has to start at that resolution: a label such as CRM or portal will absorb any answer.
The test is a single question. If a competitor bought the same subscription tomorrow and copied every field, rule, and automation in it, would the customer experience become harder to tell apart? Where the answer is yes, there is a workflow worth examining, and that is all the test establishes.
A build is a separate conclusion, and plenty of differentiating workflows run acceptably inside configured software. Two checks bear on it and are examined below: the release path the configured logic already runs on, and whether one complete slice of records can leave the product intact.
Configured Logic and Its Release Path
Configured SaaS can become a software system without anyone deciding that it has. Custom fields, formulas, validation rules, approval flows, automations, scripts, integrations, and permission sets all change what the product does. By renewal the question worth asking is how a change to that logic gets developed, reviewed, and released.
Some platforms answer that well. Microsoft documents application lifecycle management for Power Platform solutions: solutions are exported or unpacked into source control, development and production environments are kept separate, and deployment runs through build automation. The same page is candid about the limit, recommending that teams avoid having several people change complex components such as forms, flows, and canvas apps at the same time, because source control merges are limited.
An inventory answers that question, one line per rule, flow, and integration. Thin answers point at a company already maintaining custom behavior without the controls its importance deserves, which can argue for formal lifecycle management on the platform the company already owns before it argues for moving the logic into a smaller custom application. What each line has to record is where the source lives, who reviews a change to it, which environment it is tested in, how it reaches production, and how the previous version comes back.
When One Workflow Moves
The result can be mixed: the commodity systems stay, and one narrow workflow moves into software the company controls. API integration can keep the customer, order, and status records consistent across the seam. Where the differentiating rules already live in an older application that has become expensive to change, modernizing that application can be a smaller change than a new build, depending on its code and data.
The Export Rehearsal
The export request is more specific than the Export menu suggests. The HubSpot Exports API takes an object type, the properties to include, and the associated object types to bring along, and it accepts up to four associated object types per request. The limit counts types, not records, so deals and tickets spend one each no matter how many records come back. As an illustration, a customer record that needs deals, tickets, line items, quotes, and one custom object alongside it takes at least two requests and a join before anyone sees a single table.
Associations have a default ceiling as well. That API returns up to 1,000 associations per row by default and needs overrideAssociatedObjectsPerDefinitionPerRowLimit set to true on the request to go past it. The record export in the product also defaults to up to one thousand associated record ID values per association column, and offers an "All associated records (CSV files only)" option for larger relationships; calls, notes, and meetings leave through separate paths. The API and the product export have different limits, so the one actually used is the one to test. A test export checked against a small account never reaches those defaults, and the largest account, the one a migration cannot afford to get wrong, is where they apply.
One complete slice is worth reconstructing somewhere else before the renewal date: a single customer or order, everything attached to it, and enough configuration to read it. The slice has only survived the trip when all five of these arrive intact:
- Stable record identifiers and the relationship keys that still join on the other side, including any associations beyond the default per-row limit.
- Field and status history, which Salesforce keeps in per-object history objects. Its export guidance describes standard field history as accessible for up to 24 months, with data older than 18 months reachable only through Data Loader or the SOAP API, but the retention article guarantees only 18 months for orgs created after June 1, 2011, and says older rows are not guaranteed to be complete and can be deleted. The range the business needs has to be exported and checked before anyone relies on it.
- Activity records, which live in their own Task and Event objects. By default Salesforce archives ended events and closed tasks older than 365 days, a threshold an organization can ask Salesforce Support to change. Standard query() calls exclude archived rows; the API includes them through queryAll(), and ALL ROWS does the same only in Apex SOQL.
- Files still attached to their records: a Data Loader export of ContentDocument returns CSV rows rather than the documents, and the Query All Files permission widens which file records the export can see without downloading the files themselves.
- The field and workflow configuration that makes the values mean anything.
A team that cannot rebuild that slice does not have an exit plan yet, and the finding belongs in the renewal decision even when the subscription is still the right product.
Related Reading
For the data underneath either choice, read Before You Add AI, Fix the Data Retrieval Layer.