Software release readiness checklist: decide go or no-go on evidence

OutsourcingVN is operated by Netbase JSC, which builds and releases software for clients, so this checklist reflects how a delivery supplier wants releases judged. It works for any team. It draws on Netbase's Netztech Magento 1 to Magento 2 migration, a release where every extension and data set had to be checked before cutover.

Why does a release need an explicit go/no-go decision?

Without an explicit decision, a release goes out because the date arrived. The people closest to the code are the most optimistic about it, and the people who will handle the consequences, support staff and the business owner, are often not asked. An explicit go/no-go puts the evidence in front of the person who carries the risk and records what was accepted.

The decision does not have to be heavy. For a small, reversible change it can be a checklist in the pull request and one approval. For a migration or a change to payments it should be a short meeting with named roles. What matters is that "not ready" is a normal, respected answer.

What goes on the release readiness checklist?

Each line needs evidence that someone other than the author can check. The last column says when a missing line stops the release.

A release with an open item can still go, but only as a recorded exception: who accepted the risk, why, and when it will be closed.

How do release size and frequency change the checklist?

Smaller releases are easier to judge. Google's Site Reliability Engineering chapter on release engineering argues for frequent releases with fewer changes between versions, reproducible builds, and enforced policy on who may approve and deploy a change. A team releasing once a quarter needs a heavier go/no-go because each release carries more change and more unknowns.

NIST SP 800-218, the Secure Software Development Framework, is a useful reference for the security line: it describes practices such as reviewing code and checking third-party components that a release checklist can point to as evidence rather than restating.

What changes for a platform migration release?

For Netztech, Netbase delivered a Magento 1 to Magento 2 Commerce migration in 35 working days, including migrating 11 extensions with installation, configuration, customization and data transfer. A migration like that is one large release rather than a series of small ones, so the checklist grows: each extension becomes an acceptance line, and each data set becomes a reconciliation check between the old and new platforms. The Netztech migration record shows the scope that had to be covered.

A migration cutover adds lines the ordinary checklist does not have: a content and order freeze on the old platform, a final data sync, the switch of domain and payment settings, smoke tests on the live platform, and a rollback window during which the old platform stays ready. Legacy data migration planning covers the data side in more depth.

Worked scenario: a go/no-go for a checkout change

An online retailer changes its checkout to add a second delivery option. The release candidate is ready on Thursday for a Friday morning deployment.

Decision: no-go for Friday morning. Bank transfer is checked that afternoon, an alert is added for orders using the new option, and support is briefed. The release goes out on Monday morning, outside the weekend trading peak, with every line met. The delay cost one working day; a broken bank-transfer checkout over a weekend would have cost far more.

Who should take part in the release decision?

Netbase project teams draw on business analysis, project management, solution architecture, development, QA and UI/UX roles. For a release decision, the useful subset is the product owner for acceptance, QA for regression, a technical lead for security and data, the release owner for deployment and rollback, operations for monitoring, and the business owner for timing and support. One person can hold several roles; nobody should confirm their own work alone.

Netbase's delivery lifecycle runs from discovery and strategic alignment; team assembly and architecture planning; agile execution with outcome-based milestones; modular components; training and rollout; to ongoing support. Release readiness sits at the point where agile execution hands over to training and rollout, which is why support briefing appears on the checklist.

Which questions should you ask your delivery team?

• Who decides go or no-go, and what evidence do they see? Expect a named person and a written checklist.
• Has the deployment method been run before production? Look for a staging deployment using the same steps.
• How do we roll back, including data? A good answer covers both code and data, and has been tested.
• What will tell us within the first hour that something broke? Expect specific checks on the changed journeys.
• What security checks ran on this release? At Netbase, security practices include secure code review and version control, role-based access control, MFA for admin dashboards, contributors under NDA, and NDAs and DPAs on request.
• What are you accepting as a known risk? Look for a written list with owners, not "nothing".

What usually goes wrong at release time?

• Release by date. Signal: the checklist is filled in after deployment. Owner: the business owner, who makes no-go an acceptable answer.
• Data changes tested on sample data. Signal: a migration script fails on production volume or odd records. Owner: the technical lead.
• No rollback for data. Signal: the code can go back but the data cannot. Owner: the release owner, who plans data rollback before release.
• Monitoring that misses the change. Signal: the first report of a problem comes from a customer. Owner: operations, who adds checks for changed journeys; the reliability and incident readiness guide covers alert routing.
• Support learns last. Signal: support tickets about a feature nobody told them about. Owner: the business owner.
• Late additions. Signal: "one small fix" merged after the freeze. Owner: the release owner, who holds the freeze.

How this guide is sourced and where it stops

This guide draws on the release engineering chapter of Google's Site Reliability Engineering book, NIST SP 800-218 and Netbase records approved in the OutsourcingVN claim register: the Netztech migration, team roles, the delivery lifecycle and security practices. The methodology explains how those records are sourced. The checkout scenario is illustrative rather than a client record, and the checklist needs adapting to regulated releases that carry their own sign-off rules.

Check your next release against the list

Bring the release candidate, its acceptance criteria and your current deployment and rollback method. A technical audit sprint can review your release process against evidence, Managed Operations can run releases under an agreed change route, and the software takeover and maintenance guide covers the first releases on an inherited system. For systems still being evaluated, see software technical due diligence.

OutsourcingVN is Netbase's own outsourcing-services platform. Submit a project with the release you are preparing, and a person will reply with the checklist lines that most need evidence.

Related services and solutions