rand
Log inEstimate your claim

Is it eligible?

Is cloud migration eligible for the R&D Tax Incentive?

Rarely eligible

Rarely. Moving applications, databases and infrastructure to the cloud with documented tools and vendor guidance is routine re-platforming, however large or risky the project. A narrow question that the move exposes, where no competent engineer could predict the result, can be a core activity if it is scoped and recorded on its own.

Reviewed by George WalchFacts last verified

When it qualifies

A seismic solver on a slower network

An illustrative geophysics software company moves its wave-propagation solver from an on-premises cluster with a low-latency interconnect to cloud instances. Published scaling results for this class of solver assume the faster interconnect, and its engineers cannot predict whether a communication-avoiding decomposition keeps parallel efficiency above 70% at 512 cores on the cloud network. That one question is planned and tested. Moving storage, pipelines, access controls and the cutover is recorded as ordinary work.

When it does not

Leaving the data centre

A SaaS company moves from colocated servers to a public cloud: containers, a managed database, infrastructure as code and a weekend cutover. It overruns by four months after unexpected networking and permissions problems. Every component was documented and each problem was solved with known techniques. The risk was delivery, not a technical outcome nobody could predict.

The evidence that supports it

  • A separate ticket, epic or plan for the narrow question, distinct from the migration program, created when the question arose.
  • The published benchmarks, vendor documentation and scaling studies reviewed, and why they did not answer it.
  • Baseline measurements on the old platform and results per variant on the new one.
  • The hypothesis with its numeric threshold and disproof condition.
  • Time records that keep experiment hours apart from migration hours.
  • A conclusion note recording what was learned and when the question closed.

A cloud migration can be the biggest engineering project a company runs in a year, with real risk of failure. It is still, in almost every case, not R&D. The R&D Tax Incentive pays for resolving technical unknowns, and a migration mostly applies what cloud providers, tool vendors and thousands of earlier migrations have already documented.

Why migration risk is not technical uncertainty

The ATO and AusIndustry's joint alert on software claims, TA 2017/5, describes the pattern closely: a project that modifies, customises or upgrades existing software, registered as a whole, with project, commercial or economic risk mistaken for technical risk. A migration's risks are almost all of that kind:

  • Will it finish on time and within budget?
  • Will the team learn the new services quickly enough?
  • Will cutover cause an outage?
  • Will running costs come in as forecast?

None of these is an outcome that a competent cloud engineer, with access to published knowledge, could not determine. AusIndustry's software guide likewise treats migrating data with known tools and established approaches as routine, and Rand treats re-platforming and version upgrades the same way.

Carving out a genuine question

Occasionally a migration exposes a narrow technical question that published knowledge does not answer: a computation whose behaviour depended on hardware the new platform lacks, a timing guarantee nobody has measured under the new runtime, a scaling result that assumed a different network. Moreton Resources [2019] FCAFC 120 accepted that applying existing technology in a new context can be a core activity where the outcome could not be known. That principle is narrow and needs evidence.

If you have such a question, treat it as a separate activity from the start:

  1. Open a distinct ticket or plan for it, dated when it arose.
  2. Record what was searched and why it did not settle the question.
  3. State a hypothesis with a threshold.
  4. Keep its hours and costs apart from the migration program.

The activity's size should follow the question, not an expected proportion of the migration. Register the work that resolved the unknown, at whatever scale the tickets and time records show, and leave the rest of the move as ordinary work. A narrow, well-evidenced activity is easier to defend than a registration that describes the whole move as experimental.

Coordination questions of this kind are covered more fully on the distributed systems page. Linking each pull request to its ticket in a tracker such as Jira makes the separation visible later.

Edge cases peculiar to migrations

  • Database engine changes. Conversion tools and compatibility guides make most of this routine.
  • Mainframe and legacy code conversion. Automated translation followed by fixing what breaks is ordinary work.
  • Parallel running. Comparing old and new outputs to confirm they match is verification with a known expected result.
  • Internal systems. Moving your own ERP, payroll or finance system to the cloud is routine and also caught by the internal administration exclusion; see internal administration software.
  • The cloud bill afterwards. Only compute used for registered experiments counts; see cloud compute costs.

Frequently asked questions

Our migration ran months late because of unexpected problems. Is that uncertainty?
Not in the statutory sense. Overruns, unfamiliar services and surprises during cutover are project risk. Technical uncertainty means an outcome a competent engineer could not determine from available knowledge, tested by a planned experiment.
Is converting a legacy database to a different engine R&D?
Usually not. Schema conversion tools, documented compatibility guides and established approaches cover it. A specific behaviour with no published answer, measured in a planned test, could be assessed on its own.
We are moving our own finance and HR systems to the cloud. Any chance?
Very little. Beyond being routine, software developed or customised for the dominant purpose of the company's internal administration is excluded from core R&D.

Sources

  1. AusIndustry (business.gov.au): Software development sector guide
  2. ATO: Taxpayer Alert TA 2017/5
  3. AusIndustry (business.gov.au): Excluded R&D activities under the R&D Tax Incentive

The R&D Tax Incentive is a self-assessment program. This page is general information, not tax, legal or financial advice; eligibility depends on your circumstances and you should seek independent advice for them.