SR&ED by domain — Cloud computing

SR&ED in cloud computing and infrastructure

Distributed systems, container orchestration, fault tolerance, cost per request: cloud engineering teams spend a large share of their time solving problems with no known solution. That is the definition of experimental development under SR&ED.

Three-dimensional rendering of cloud infrastructure connected to a cluster of servers.
  • Distributed architecture and fault tolerance
  • Orchestration, scaling and load optimisation
  • Multi-tenancy and data isolation
What SR&ED funds

SR&ED applied to cloud computing

SR&ED is Canada's federal tax credit for scientific research and experimental development. A Canadian-controlled private corporation recovers up to 35 % of its qualifying expenditures as a refundable cash payment, on a base of up to $6M per year; in Québec, the CRIC adds 30 % on the first $1M. In cloud computing the base is almost entirely engineering salaries — which makes the split between qualifying work and routine operations the single decision that drives the final number.

  1. 01

    Reliability engineering is under-claimed

    Designing a failure-recovery mechanism that holds at scale without degrading latency is not maintenance. Most SRE teams book that work to "operations" out of accounting habit and remove it from the base without noticing.

  2. 02

    Performance as technological uncertainty

    When a latency or cost-per-request target cannot be met by documented means, the search for an architecture that meets it qualifies — including the approaches abandoned along the way.

  3. 03

    Servers are not qualifying expenditures

    Hosting, rented instances and licences cannot be claimed under SR&ED, contrary to a stubborn belief in this sector. What is claimable is people’s time. A claim that inflates the base with cloud invoices simply loses that line.

Qualifying work

Examples of eligible projects

Work that commonly qualifies among our clients in this sector. This list illustrates; it does not enumerate. A project absent from it is not a project excluded.

Commonly qualifying in this domain

  • Designing a distributed consistency or replication mechanism
  • Scheduling and autoscaling under highly variable load
  • Reducing tail latency where known optimisations fail
  • Multi-tenant architecture with strict data isolation
  • A migration requiring a rewrite of a component with uncertain behaviour
  • High-throughput observability without degrading the observed system

The sector trap: claiming the migration itself. Moving an existing workload to a cloud provider by following a documented procedure is integration work, not SR&ED. What qualifies is the component you had to design because no procedure existed.

FAQ

Frequently asked questions

  • Part of it. Routine operations — monitoring, patching, standard deployments — do not. Designing a deployment, recovery or scaling mechanism whose behaviour cannot be predicted from known practice is experimental development. The question is never the job title; it is the nature of the problem being solved.

Have your cloud infrastructure work assessed

Check my eligibility