Government of Canada
The 2026
Digital Lifecycle Guide
This is a guide for people who work on digital services for the Government of Canada. You could be anyone: any role, any background, a small team or a large one.
You might build in-house, contract a team to build, or buy from a supplier. Your budget might be generous or almost nothing. None of that changes what follows, because this guide is about the practices that matter for any digital work, at any size.
What this guide is
It describes a few ways of building a digital service, not the only correct way, because there is not one.
Take a department with money for a service, no technical staff of its own, and a date somebody else set, because a minister announced it or the legislation names it. Going to a large supplier and paying them to work out most of the detail may genuinely be its best option. That skips almost everything described here, and it can still be the right decision.
So the guide stops short of telling you exactly what to do. The right answer depends on things only you can see: your deadline, your budget, who you have, and what your department is already committed to.
What is here for you, whichever way you go
The security practices. Every service needs them, whether it was built in-house, bought whole, or assembled from something that already existed.
The official checkpoints. The assessments, approvals and authorizations a Government of Canada service has to clear. They will find you whichever route you take, and each one is cheaper to prepare for than to be surprised by.
A picture of what is coming. Which decisions arrive in roughly what order, who else has to be involved, and which of them are expensive to reverse later.
One thing that catches people whichever route they take
If the new service is replacing something, keep the old one running until the new one has carried real volume for a while and held. It is tempting to switch off early, because running two things is awkward and somebody is usually asking when it will stop. But nothing before launch tests real volume, people need time to move across, and once everyone has moved there is no way back. If the new service then struggles, the department finds itself negotiating changes with a supplier it can no longer walk away from, which is an expensive place to be standing.
The same thing read backwards is a planning problem. If something is going to replace a service you already run, the replacement has to be funded, competed, built and steadied before the old one can be switched off. Counted backwards from the day you would like the old service gone, that is usually years, and for much of it a department pays for both.
The one thing worth holding on to
It stays your service. You can hand the building to a supplier, and much of the time that is the sensible thing to do. What does not transfer with it is the answering for it. When a service does not work, the person who cannot get their application in never hears about the procurement contract behind it, and would not care if they did. They experience it as the Government of Canada failing them, and it is the department that answers for that, publicly and afterwards.
Which is why it is worth the effort to understand what you actually want, and what you are buying, well enough to say both plainly. A supplier given a vague description will build something roughly as vague, in much the way a vague prompt to an artificial intelligence tool returns something you did not quite ask for. Neither is anyone behaving badly. It is just what happens when the description was not clear enough to build from.
Who this is for
This guide is for you, whatever brought you here
Some people reading this know exactly what they own. Their department's application register has their name against a system, and once a year somebody asks them to rate its health.
Most do not. They think of themselves as running a program. A grant, a licence, a benefit, an inspection regime. Each of those has a digital solution, and someone is accountable for that solution.
You might be:
- a business owner already named against a system in your department's application register
- a program manager whose process has stopped coping with the volume
- a policy lead who has been told to deliver something by a date
- a director general who has inherited a system nobody can fully explain
- a project manager handed a service that is already live
- someone who has just been told there is money to buy a system
- or in any of the other positions people find themselves in when a service becomes their responsibility. The list is not meant to be complete.
You may never have chosen any of this. It does not matter how you arrived.
If a digital service delivers your program, or one is about to, you are its business owner. You are accountable for it from before it exists until after it is switched off. This guide is for you.
See the whole path
Checkpoints a GC digital service has to pass
Here is the entire lifecycle on one page: every official approval, review, and sign-off a service passes through, from the first problem to retiring or replacing it, who owns each one, and roughly how long it takes.
The three phases
Every digital service, whatever it does, runs into the same handful of questions over its life. What problem are we solving, and for whom. Is the solution working for the people who use it. Is it still the right solution. When is it time to let it go. The questions repeat. What changes is where you are in the life of the service when you ask them.
The lifecycle falls into three phases: Create, Live, and Sunset. A phase is a big chapter in the life of a service.
Each phase has smaller parts, called sub-phases. Create has Discovery, Alpha, and Beta. Live has Stabilization, Growth, and Maturity. The phase is like the chapter of a book; the sub-phase is the page you are on within it.
Whichever phase you are in, one idea runs under all of it: a government service is almost never the thing a person actually wants. It is one step in a much bigger journey of theirs, often spread across many departments and levels of government. Joined-up delivery is where that thinking starts.
Why it matters
Set the guide to your situation
This guide has two settings that change what you see throughout. Pick what fits your situation. You can change your mind later.
Buy vs build
The practices stay the same. What changes is who does the work — your team, a supplier, or both.
Size
The practices apply at any size. What changes is how heavy each one is.
For your setup
Pick either setting above and this note will change to match.
A guide for the next guide
This is a first attempt, written in a few months. If somebody picks the work up later, here is what would have been useful to know at the start.
Why we could not simply follow the UK and Australia
The two guides we looked at most were the United Kingdom's Service Manual and Australia's service design and delivery process. Both draw firm lines between phases, and both can, because each is written for one situation: a small team of public servants building a service themselves, on shared infrastructure and reusable components their government has already built for that purpose.
Most existing Government of Canada services were bought rather than built by the department itself, and how you buy changes when things happen. Three examples:
- A department that contracts a team. It runs the competition during Discovery and signs as Alpha begins, because the contracted team is who builds the prototypes.
- A department that buys a finished product. It competes during Alpha and signs as Beta begins, and never builds a prototype at all, because the product already exists.
- A department following the agile approach Public Services and Procurement Canada sets out. It competes during Discovery, signs with several suppliers at once as Alpha begins, and each of them builds a prototype under that contract. The winner is chosen by amending their contract rather than by running a second competition.
The competition, the signature and the first real build are the same three events in all three cases. Where they land moves by a whole sub-phase, and the only thing that moved them is how the department chose to buy. That is why this guide describes each sub-phase more loosely than the guides it learned from.
And the part that is not really about the guide
No guide can tell a department how its particular service will go. What it can do is leave the reader harder to surprise. If the next version of this does one thing better, we would like it to be that: fewer people finding out about a decision at the point where it has already been made for them.
Assumptions this page makes
You are already working to the Government of Canada Digital Standards, design with users, iterate and improve frequently, work in the open, use open standards, address security and privacy, build in accessibility, empower staff, be good data stewards, design ethical services, and collaborate widely, and to the law on privacy, security, official languages, and accessibility. The standards say how the government works in the digital world. The six Government of Canada digital competencies say what every public servant has to be able to do to work that way, and the team page covers them. This guide builds on those.