Technology integration should be treated as a service-continuity project, not a post-settlement IT tidy-up. Before completion, a buyer should know which systems hold the client record, how work moves between them, who controls each licence and administrator account, and whether the buyer can reproduce critical lodgment, billing and document workflows on day one.

The central decision is not automatically “move everything to our platform”. A buyer may migrate immediately, operate both stacks temporarily or retain selected seller systems. The right approach depends on data quality, contract rights, workflow differences, staff capability, regulatory obligations and the acquisition timetable. Price the chosen operating model—and a credible failure scenario—before treating claimed software savings as acquisition value.

Build a system and dependency map

Start with a complete register, not just the general ledger and tax-production software. Include practice management, client portals, document management, email, telephony, workflow, time recording, billing, payments, payroll, digital signatures, company-secretarial tools, reporting, password management, backups, integrations, spreadsheets and any seller-built scripts.

For each system, record:

  • legal subscriber, contract term, renewal date, user count and actual monthly or annual cost;
  • product edition, hosting model, database location and supported version;
  • administrator, privileged users, external IT provider and recovery contact;
  • integrations, add-ons, API connections and manual exports feeding other processes;
  • data sets held, retention settings, archive format and export capability;
  • ownership-change, assignment, termination, price-review and data-extraction terms; and
  • operational owner, peak-period use, known defects and unavailable workarounds.

Then draw the dependencies. A client record may begin in a practice-management system, feed a tax product, create documents in another repository, obtain approval through a portal and generate an invoice elsewhere. If the buyer tests only whether client names can be exported, the material workflow may still fail.

Verify what can actually transfer

Ask vendors in writing whether subscriptions, historical data, integrations and support arrangements can move to the buyer’s entity. A seller login is not a transferable asset. Establish whether licences are attached to an entity, individual practitioner, office, client count or product bundle; whether the seller has prepaid amounts or minimum terms; and whether a change of control triggers consent, repricing or a new contract.

For products that transmit taxation, accounting, payroll, business-registry or superannuation data through ATO digital services, check the actual product and authorised services against the ATO’s Product register. The ATO says listed commercial products have met the relevant Digital Service Provider Operational Security Framework requirements and are authorised for specified connections, but it expressly does not endorse the products or guarantee vendors’ descriptions. Registration therefore does not answer whether a particular product, edition or workflow suits the buyer.

Confirm who owns custom templates, automations, reports and integrations. Obtain source files, configuration documentation and support arrangements where relevant. If the “system” depends on one employee’s macros or the seller’s undocumented sequence of steps, it is key-person exposure disguised as technology.

Protect the complete client record

Migration scope should be defined at record level. Test whether the export includes source documents, workpapers, correspondence, file notes, approvals, calculations, lodgment receipts, task history, billing records, metadata and audit trails—not merely balances and contact details.

The Tax Practitioners Board says registered tax practitioners must keep records that correctly record the tax agent services provided, retain them for at least five years after the service, and keep electronic records readily accessible and retrievable. Copies must be true and clear, and the record should be protected from change or damage (TPB). A migration that produces attractive client folders but loses evidence of advice, review or outcome may create an operational and professional problem.

Agree objective acceptance tests: select samples across entity types, services, years and file sizes; export them; import them into the target; and have technical staff and practising accountants independently verify completeness, readability, searchability and permissions. Reconcile record counts and exception logs. Preserve a controlled archive if some data cannot be imported, with documented access, retention and exit arrangements.

Test ATO connections and production workflows

ATO-facing access must be planned around the buyer’s entity and authorised users rather than copied from the seller. Under the ATO’s cloud software authentication and authorisation model, a provider issues a unique Software ID and the business or tax practitioner authorises that provider through Access Manager; on transmission, the ATO verifies the authorisation, Software ID and, for registered agents, the relevant client relationship (ATO).

Build a cutover checklist for Software IDs, Relationship Authorisation Manager roles, Access Manager settings, machine credentials where used, agent numbers, client relationships and vendor provisioning. Have the relevant vendor and specialist confirm the steps for the actual structure. Test a low-risk end-to-end transaction before a deadline peak, including preparation, review, client approval, transmission, receipt, document filing and status update.

Also test ordinary work. Can staff open prior-year files, roll forward workpapers, retrieve permanent documents, send from the correct domain, issue an invoice, record payment and see the same status in the workflow system? A successful database import does not prove the practice can deliver work.

Choose a transition model deliberately

Compare three models rather than defaulting to the most familiar one:

Model When it may fit Evidence needed
Immediate migration Stack and data are compatible; timing avoids peak work Completed trial migration, reconciled exceptions, trained users and rollback plan
Phased migration Client groups or service lines differ materially Wave criteria, dual-system ownership, cut-off rules and a dated end state
Temporary coexistence Immediate change would disrupt deadlines or client service Integration controls, duplicate-record rules, support cost and exit timetable

Quantify the full cost of each option: licences, migration, configuration, data cleansing, hardware, vendor and consultant time, staff training, temporary productivity loss, parallel operation, archive access and contingency. Deduct obsolete seller licences only when termination and replacement timing are evidenced.

For members subject to APES 325, the standard requires a documented firm risk-management framework and links effective risk management with business continuity and quality service delivery (APESB). Use a named owner, risk register, decision log, escalation path and tested fallback rather than relying on an informal IT to-do list.

Investigate vendors and cloud exit risk

Review service levels, outage history, support response, subcontractors, data location, recovery commitments, backup coverage and the format and cost of a full export. Ask how long access remains after termination and how the provider confirms deletion. The OAIC’s cloud guidance asks entities to perform appropriate service-provider due diligence, define contractual information-handling obligations, understand shared controls, confirm recovery capability and ensure data remains retrievable in a usable format (OAIC). Privacy coverage and detailed cyber controls require separate specialist review; for integration planning, the immediate question is whether the buyer can control, recover and exit the service without losing the client record.

Set completion gates

Do not leave every technology issue for the first week of ownership. Before completion, seek:

  • signed vendor consents or replacement agreements where required;
  • a reconciled data inventory and successful sample migration;
  • buyer-controlled administrator accounts and recovery methods;
  • confirmed ATO and other external-service authorisation steps;
  • a cutover runbook, downtime window, staff roster and client-communication trigger;
  • backup, rollback and read-only archive arrangements; and
  • a post-migration defect process with named owners and response deadlines.

Unresolved items may require a condition, seller action, specific handover support, retained access, revised cost forecast or a later migration date. Legal, accounting, tax, privacy, cyber and technology advisers should shape those responses for the actual deal.

Sources

Disclaimer

This article provides general information only. It does not constitute legal, tax, accounting, financial, credit, valuation or other professional advice. Circumstances differ. Obtain advice from appropriately qualified advisers before acting or entering a transaction.