Avoid over-customising
When you buy software that already exists, the strongest thing you can do is leave it alone.
The table with a hole in it
Say you buy a good, standard table. Then you cut a hole in it to fit one particular machine you own. Now the table only works for that machine. You cannot use it for anything else, and you cannot sell it on. You have traded a thing that fit many needs for a thing that fits one.
Customising bought software does the same. You bend it to fit the one way you happen to work today, and in doing that you make it yours alone, good for nothing but the job you bent it toward.
Why customising hurts later
The real cost shows up at upgrade time. The supplier ships a new version with improvements you would have got for free, but your copy is full of your own changes. Before you can take the new version, you have to redo every change on top of it.
So you either fall behind on an old version, or you pay again and again to carry your changes forward. Every upgrade becomes a project. Customise far enough and the software can no longer be patched at all, and a security fix you need becomes one you cannot take.
Bend the process, not the software
When you buy, shape your process around the software. Your way of working can flex: you can change a form, a step, a habit. Keep the bought thing as close to standard as you can, because standard is what stays cheap to run, easy to patch, and safe to upgrade.
Sometimes a small change really is needed. When it is, make the smallest one you can, and write down why, so the next person knows what it cost. The goal is not zero changes at any price. It is to treat every change as a debt you will pay back at every upgrade, and to take on as little of it as the work allows.
A migration is the moment to drop this. TBS's GCcase migration guidance advises against rebuilding the old solution as it was, since many customisations exist only because of an old platform's limits and are not needed in a modern one.
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.