Migrating to the cloud without losing control of your data

Which decisions come before migrating anything?

Three, and none is technical. Where the data lives and under which law; what stays on premises and why; who operates it after the cutover. Without those answers in writing, the organization inherits a hybrid architecture it endures rather than chose, and a bill that drifts month after month.

These three decisions are rarely taken because they belong to management rather than to engineering. Deferring them does not cancel them: they then get taken by default, migration by migration, with nobody having arbitrated.

• Data residency. It determines the applicable law, notification obligations, and what you will have to demonstrate to a customer or a regulator. It is decided per data category, not globally.
• What stays on premises. Some workloads gain nothing from moving: hardware dependencies, critical latency, hardware-bound licences. The trade-off is made workload by workload, with the reason written down.
• Who operates it afterwards. Migration relocates the operational burden, it does not remove it. A team that managed servers will manage subscriptions, identities and costs: a different trade.

Is the cloud compatible with Law 25?

Yes, provided the question is treated as an architecture decision. The law does not forbid hosting outside Quebec: it requires a privacy impact assessment before any disclosure outside, and contractual framing of the provider. What is settled up front becomes expensive to retrofit.

In practice the difficulty is documentary rather than legal. Most organizations do not know which data goes where, because the question was never asked department by department.

A second point recurs: onward subcontracting. A provider located in Canada may itself rely on infrastructure elsewhere. The assessment covers the real chain, not the address of the provider's head office.

We therefore work through this alongside the data mapping, before design, not as a checkbox at the end of the project.

How do you avoid cost drift?

By treating cost as a design constraint rather than a billing topic. Sizing, automatic shutdown policies, storage class per data type, and cost attribution per department are decided at architecture time. Retrofitted afterwards, each of those means revisiting choices already deployed.

The most common drift does not come from oversizing but from the absence of an owner. When nobody is responsible for a resource, nobody stops it: test environments run overnight, backups accumulate, volumes stay attached to deleted machines.

The second factor is data transfer. It is rarely estimated at design time and surfaces on the invoice, particularly in hybrid architectures where site-to-cloud exchange is frequent.

Attributing spend per department or per application is the most effective lever, because it makes cost visible to whoever generates it.

Azure or AWS: how do you decide?

Rarely on technical capability, which overlaps heavily for the needs of a small or mid-sized organization. The decision rests on what already exists (directory, licences, internal skills)and on your teams' ability to operate the platform day to day.

An organization whose directory and productivity suite already sit with one vendor reduces complexity by staying in that ecosystem: fewer integrations to maintain, a single identity model, and often entitlements already owned.

Conversely, a particular application workload or an existing internal skill set can justify the other choice. Multi-cloud, meanwhile, is rarely decided for good reasons in a mid-sized organization: it doubles the surface to master for a theoretical benefit.

We resell no licences and are not a reseller for either platform, which makes this trade-off verifiable.

Frequently asked questions