Commercial HVAC platforms: consolidating service agreements and BAS data

Why service agreements come before software#

Service agreements come before software because they are what a commercial HVAC platform actually bought: recurring maintenance revenue tied to specific buildings, equipment and response commitments. Each tuck-in wrote them differently. One kept PM schedules as recurring jobs in its field service platform, another as Word documents with an equipment spreadsheet attached, a third as purchase orders from a property manager.

Migrating software before normalizing agreements carries every inconsistency into the new system. The goal is one register where each agreement has the same fields, so the platform can price renewals consistently, staff PM visits across branches and see which customers already hold agreements with several of its companies.

What BAS data does a mechanical contractor actually control?#

A mechanical contractor usually controls very little BAS data outright: the building automation system, its controllers and its trend logs normally belong to the building owner, and the contractor works inside them with permission. What tuck-ins tend to hold are copies, such as trend exports pulled while troubleshooting, alarm histories, points lists, graphics, sequences of operations and controller program backups.

Who may keep and use those copies depends on the original install contract and the current service agreement, and many older agreements say nothing about data at all. Treat silence as a reason to ask the owner, not as permission.

The integration sequence for a tuck-in#

The integration sequence runs rights checks before migration, so the platform never loads BAS data into central systems it has no permission to hold. Each step depends on the one before it, and skipping ahead is the usual source of rework.

Inherited BAS credentials deserve their own pass during that inventory. Tuck-ins often keep logins on a technician's phone, in a shared spreadsheet or on a controls laptop. Move them into a vault only after each owner confirms the access should continue under new ownership, and revoke access held by departed employees at the same time.

• 1Secure read access to each tuck-in's field service platform, accounting system and shared drives before any user accounts are closed.
• 2Build the agreement register and flag assignment clauses and national-account master agreements for counsel.
• 3Attach each agreement to a site and an equipment list, and deduplicate buildings served by more than one company.
• 4Inventory every remote BAS connection, VPN, cloud portal and stored credential, with the customer who granted it.
• 5Record, building by building, what the agreement allows the contractor to access, copy and keep.
• 6Load agreements, sites, equipment and open work into the platform system, then rebuild PM schedules.
• 7Export history from the retired system and keep it read-only.

Exporting history before a field service system is retired#

History from a retired field service system should be exported in full before the subscription ends, because default report views often show less than the account holds. ServiceTitan's migration guide for FieldEdge, for example, says to set every filter on the Invoices tab to All before exporting, so the file includes all invoice data rather than only the previous six months.

The records most often lost are the ones that matter most to commercial customers: warranty claims, deficiency lists from PM visits, refrigerant repair notes and startup reports attached as files. Check that attachments come out with the work orders they belong to, not as a loose folder.

Check platform terms before connecting AI tools#

Platform terms decide whether a consolidated field service system can be connected to AI tools at all. ServiceTitan's terms of use say users must not let any third party, expressly including any AI agent, access or use ServiceTitan technology, and its API and data authorization terms make the customer and its authorized partners solely responsible for complying with export and privacy laws when customer data moves to those partners.

Read the current version of each vendor's terms before an operating team wires an assistant into dispatch or service history. Record the version and date reviewed, since vendors update terms.

Illustrative: three mechanical companies, one register#

Illustrative: a fictional commercial HVAC platform owns a mechanical service contractor in one metro area and acquires two tuck-ins, a controls integrator and a refrigeration service company. The controls integrator holds remote access to many customer buildings and keeps controller backups on a shared drive. The refrigeration company tracks its agreements in spreadsheets.

The operating partner orders the agreement register first and finds that several national-account master agreements require notice of a change of control, which counsel sends before rebranding. The BAS inventory turns up credentials stored in a shared spreadsheet; the platform moves them into a password vault after each owner confirms access, and drops connections to buildings whose agreements had lapsed. Trend exports stay attached to the jobs that needed them until owner terms are confirmed.

Consolidated service records, AI and SourceX#

Consolidated service history, including work orders, PM findings, refrigerant repairs, callbacks and equipment failures, is the record family most relevant to AI developers building maintenance and diagnostic tools. Records the contractor created, such as technician notes, quotes and repair outcomes, are generally simpler to clear than BAS data copied from customer systems.

SourceX handles this through the SourceX five-step transaction: Supply, Rights, Preparation, Approval and Delivery. The Rights step separates contractor-created records from owner-controlled BAS data, Preparation removes customer names, addresses and other personal or confidential details, and the supplier approves every step. Large archives stay in the platform's own storage.