Hero image: Original AI-assisted illustration created for this article.

Importing a contract and moving its billing are different operations. A team can reproduce an agreement's dates and line items accurately while leaving two systems prepared to charge for the same future period.

That is why a Revenue Hub migration should begin with the next invoice, not with the import file. The most consequential question is which system owns each future billing instruction, especially when the customer renews, expands, or changes terms during the transition.

Disclosure: I am the founder and CEO of INSIDEA, an Elite HubSpot Partner. This article reflects practical experience and independent research. It is not sponsored by HubSpot or any other company mentioned.

I would treat contract migration as a controlled transfer of responsibility. A successful import is one piece of evidence. The full acceptance test is whether the team can explain the active agreement, the next bill, the collection method, and the system responsible for each action without creating duplicates or losing history.

Separate visibility from billing ownership

HubSpot's direct-contract guide documents direct creation and import under a beta path. It distinguishes ordinary imports without billing schedules from a separate billing-continuity migration path. It also documents billing and collection configuration. Do not treat a record import as proof that recurring billing has moved.

The implementation model below is a proposal. Example registers, states, and test cases are not native HubSpot objects or a claim that every account can perform the same migration. Verify supported paths, eligibility, payment processing, and permissions in the account before planning a production cutover.

A visibility-only contract can be valuable. It can give customer-facing teams a view of the agreement while the established billing system remains authoritative. That is a legitimate architecture if the boundary is explicit and the record does not misleadingly suggest that HubSpot owns collection.

Build a responsibility register

For every agreement in scope, record the authoritative system for commercial terms, billing schedule, invoice issuance, collection, adjustments, and accounting export. Include a named owner and the evidence required to transfer each responsibility.

Do not use a single migration-complete flag for all six. A contract may be visible in HubSpot while collection remains external. An accounting connector may be reconciled while payment-method transfer is still unresolved. Those are separate states, not minor details beneath one green status.

An illustrative register might contain:

Responsibility	Before cutover	After cutover	Acceptance evidence
Agreement record	Existing system	Chosen contract owner	Terms and associations checked
Next invoice	Existing billing	Chosen billing owner	Schedule reconciled
Collection	Existing processor path	Approved processor path	Method and authorization verified
Adjustments	Finance process	Approved finance process	Correction trail retained

The chosen owner may remain the same for some rows. Migration does not have to mean moving every responsibility at once. It does require avoiding two active owners for one billable obligation.

Original AI-assisted illustration created for this article.

Establish a commercial baseline

Capture the agreement as of a defined checkpoint. Include customer identity, billing entity, currency, term dates, recurring and one-time items, billing cadence, open invoices, approved adjustments, renewal terms, and pending amendments.

The baseline should distinguish committed terms from disputed or proposed changes. A salesperson's planned expansion is not an accepted amendment. A draft renewal is not the next active contract. An overdue invoice is not a reason to rewrite the commercial record to match the collected amount.

Reconcile the baseline with the people authorized to interpret it. Technical teams should not invent the treatment of unusual terms or decide how revenue should be recognized. Route accounting and legal questions to the appropriate owners, while documenting the resulting implementation decisions.

Freeze only the scope necessary for the cutover, and specify how urgent changes will be handled. An undocumented freeze creates shadow updates. A controlled exception process can preserve continuity without pretending the business will stop changing for the convenience of an import.

Classify amendments as dated revisions

An expansion, contraction, date correction, billing-contact update, and renewal are not interchangeable edits. Classify the change before choosing the mechanism that applies it.

HubSpot's contract overview describes change quotes and direct-edit paths with different requirements. It also states that an accepted renewal quote creates a new contract associated with the prior one. Those lifecycle relationships should be preserved rather than flattened into a single continually overwritten record.

For a hypothetical expansion, retain the agreement before the change, the approved amendment, the effective date, the affected line items, and the expected billing consequence. A proposed amendment can have a future effective date without changing what the customer owes for the current period.

Use separate evidence for agreement acceptance and system execution. The customer may approve a change before the billing system applies it. Conversely, a system edit may occur without sufficient business approval. Both mismatches should be visible in an exception queue.

Prove proration with fixtures, not intuition

Proration is a policy implemented through software. The result can depend on effective dates, billing periods, currencies, rounding, credits, and the treatment of previously issued invoices. A short arithmetic formula is not enough to describe every commercial arrangement.

HubSpot's contract setup documentation includes proration and renewal settings. Verify the actual configuration and supported behavior before modeling expected results. Do not assume an example from another account proves your account's outcome.

Build synthetic fixtures for a mid-period increase, a mid-period decrease, a future-dated change, a change near a renewal boundary, and a change after an invoice has already been issued. For each fixture, finance should approve the expected commercial treatment before the engineering test is judged.

Retain the calculation inputs and expected document sequence. When a result differs, classify whether the issue is a setting, an unsupported scenario, an incorrect exp