AWS Migration
Moved the entire platform off KNALYSIS and onto Canopy infrastructure.
RolePlatform engineer, working the migration with a four-person team
The platform was still running on KNALYSIS infrastructure that Canopy did not own or control. Every change depended on an external environment, and the longer the arrangement lasted the more the estate accumulated configuration nobody had authored and nobody could safely touch.
Mapped the running estate against what the product actually required, then moved workloads onto Canopy-owned AWS accounts in stages rather than as a single cutover. Working through it as a team meant the operational knowledge transferred with the systems instead of staying with the previous owner.
Canopy now owns and controls its own infrastructure end to end, with primary data sitting in Canadian regions. That last part matters more than it sounds: you cannot make a residency commitment about infrastructure somebody else runs, so this is what made the compliance question answerable at all. The migration also surfaced the security and cleanup work that became the next phases of the project.
Security Hardening
Brought the inherited estate under clear ownership and control.
RoleSecurity and platform engineer, audit through rotation
Infrastructure inherited through a migration carries whatever access patterns the previous owner happened to leave behind. Credentials had accumulated across services without a clear owner for each, and the estate still ran services the product no longer depended on. Every one of those is something that still has to be patched, monitored, and reasoned about at two in the morning when something breaks.
Audited what each credential actually reached before changing anything, so consolidation would not take down live systems. Rotated and reduced access down to a single clear owner per service, then worked through the inventory and decommissioned what was no longer in use. Reducing the estate was the point: the most reliable way to secure a service is not to be running it.
Access is now scoped and attributable. Every credential has one owner and a known blast radius. The running estate is materially smaller than what the migration inherited, and the surface that has to be defended shrank with it.
Multi-Factor Authentication
Three ways to prove who you are, so no clinic gets locked out.
RoleEngineer, authentication flows and enrolment
Access to a platform holding clinical data rested on a password alone. In healthcare that is the wrong place to stop. Passwords get reused across systems, shared between staff on a busy floor, and phished, and with a single factor any one of those is enough on its own.
Shipped three enrolment paths (authenticator app, SMS and email) rather than mandating one. Clinic staff work across shared workstations, personal phones and desk phones, and a single-method rollout would have locked out whichever group it did not fit. Offering all three meant MFA could be required without carving out exceptions that quietly become the norm.
Every account is now protected by a second factor, and staff choose the method that matches how they actually work. A leaked password on its own is no longer enough to reach anything.
- 3Enrolment methods
French Localization
Quebec clinic staff work in the language they think in.
RoleEngineer, internationalization and translation delivery
The platform shipped in English only, while a significant share of clinic users and staff work primarily in French. In Quebec that is not just a usability gap, it is a regulatory expectation. It is also a safety one: asking clinical staff to work in a second language invites exactly the kind of misreading that healthcare software cannot afford.
Retrofitted internationalization across an interface that had been built assuming one language, which meant pulling hard-coded strings out of the components rather than simply adding a translation file. Prioritized the clinical and administrative paths staff use daily so the translation landed where comprehension actually carries risk.
Staff work in French or English by preference. The platform meets Quebec language expectations, and the groundwork now exists to add further languages without repeating the retrofit.
- 2Languages supported
Interface Modernization
A calmer interface for people who stare at it all shift.
RoleFrontend engineer, design and implementation
Clinic staff live in this software for entire shifts, often on shared workstations in rooms where a bright screen is the wrong thing to have. Navigation took permanent space from the content people were actually there to read, and the interface had not kept pace with the platform behind it.
Added a dark theme built on proper contrast ratios rather than an inverted palette, so it holds up in dim clinical rooms without sacrificing legibility. Rebuilt the sidebar to be fluid, so it expands when someone is navigating and gets out of the way when they are working. That gives screen space back to the content, which matters on the smaller displays these workstations tend to have.
The interface now suits the environment it is used in. Staff choose the theme that suits their room and their eyes, and the working area grew without anything being taken away.
Environmental Integration Layer
Staff learn one interface, however many systems we add behind it.
RoleEngineer, integration architecture, with Maintenance & Environmental Control
The estate runs horticulture controllers, HVAC and building systems over BACnet and Modbus, PLCs and SCADA, plus standalone sensor networks that answer to none of them. Each one arrives with its own interface, its own vocabulary, and its own idea of what a reading even is. Every system added to a site meant retraining the staff who operate it, and that cost lands on the same people every time the estate grows.
Building an abstraction layer that normalizes every system to one shared model, so the frontend speaks a single vocabulary no matter what sits underneath. This is a deliberate trade. It pushes the real complexity onto the development side, since every new vendor needs an adapter written against the common model, and that is the point: the complexity stops there instead of reaching the people operating the building. Designing it with the Maintenance and Environmental Control team is what keeps the model honest to how these systems behave in practice rather than how their documentation claims they do.
In progress. The target is that adding a system becomes a development task rather than a training event, so Canopy staff learn the interface once and keep that knowledge as the estate expands.
Canadian Data & Health Compliance
Mapping what actually applies before anyone claims we comply with it.
RoleEngineer, gap analysis and the technical controls behind it
- 4Regimes in scope
Four separate regimes land on the same systems here. PIPEDA covers personal information federally, Quebec Law 25 adds consent, breach reporting and rules about moving data out of the province, provincial health information law applies wherever we hold identifiable client health records, and the Cannabis Regulations impose their own record and retention obligations on top. They overlap in some places and pull in different directions in others, and none of it had been mapped against what we actually run. Compliance is not in place today. Saying that plainly is more useful than assuming it is.
Working through each regime against the real system inventory rather than against a generic checklist, because the only questions that matter are specific: what personal and health information do we hold, where does it physically sit, who can reach it, and how long do we keep it. The AWS migration put primary data in Canadian regions, which is the part that makes residency controllable at all, though some services still run in the US and Law 25 expects a transfer like that to be assessed rather than assumed. Where controls were obviously needed and obviously missing, they shipped ahead of the analysis: MFA on every account, credentials scoped to a single owner, and a service estate small enough to actually reason about.
In progress, and deliberately framed as a gap register rather than a compliance claim: which obligations apply to which systems, what already satisfies them, and what does not. Law 25 expects a privacy impact assessment before new systems go live, so having this mapped now is what stops the next project inheriting the same unknowns.