Make the test outcome measurable

Sign-off is the moment your business formally accepts a delivered piece of software against the criteria you agreed at the start. It is not a casual thumbs-up after a quick demo. It is a contractual act that typically triggers final payment, shifts certain risks from the supplier to you, and may start the clock on warranty or support periods.

For internal business systems, CRM builds, customer portals and legacy modernisation projects, sign-off matters because the software will likely run your operations for years. A rushed or poorly defined sign-off creates disputes, delays further work and can leave you unable to prove that the supplier failed to deliver what was agreed.

What sign-off actually covers

Sign-off should relate to a specific scope, not to a general feeling about the project. That scope is usually defined in your specification, requirements document or statement of work. The sign-off itself confirms that the delivered software meets the acceptance criteria attached to that scope — nothing more, nothing less.

Typical elements included in a sign-off decision:

  • All acceptance criteria documented at the start have been tested and passed
  • Known defects have been classified and either fixed or formally accepted as minor
  • Agreed documentation has been delivered (user guides, admin manuals, data schemas)
  • Access credentials, infrastructure details and source-code repositories have been handed over where contractually required
  • Training has been completed for the roles that need it

Sign-off does not mean the software is perfect. It means it meets the threshold you defined. If that threshold was vague, sign-off becomes a source of conflict rather than a clean handover.

Who should sign off

The person signing off should have the authority to accept the delivery on behalf of the business and the operational knowledge to confirm that the software does what the business needs. In practice, this is often the operations manager, product owner or project sponsor — not a junior staff member who attended the demo, and not the supplier's account manager.

If multiple departments use the system, confirm that each relevant stakeholder has reviewed the parts that affect their work before a single sign-off is issued. A finance manager may need to confirm that billing outputs are correct; a compliance officer may need to confirm that audit logs capture what the business requires.

CRM and business-system builds

When accepting a custom CRM or internal admin system, sign-off should cover not just the interface but the data model and the workflows. Check that the fields your team actually uses day to day are present and correctly typed. Verify that automated workflows — such as lead assignment rules, approval chains or status-change triggers — behave as specified under realistic conditions, not just with test data that was carefully constructed to pass.

Ask specifically whether the sign-off covers data migration accuracy. If historical records were moved from a legacy system or spreadsheet, the acceptance criteria should include a reconciliation step: record counts, spot checks on key accounts and confirmation that no data was truncated or corrupted during the import.

Customer and partner portals

Portal sign-off needs to account for different user roles. A supplier may demonstrate the portal using an admin account that has full access, masking the fact that a customer-level account cannot perform a task the business assumed would be available. Before signing off, log in as each role type and walk through the processes those users will actually perform.

For portals handling documents or applications, check that file uploads, downloads and status tracking work with the file sizes and formats your users will genuinely submit, not just the small PDFs used in testing.

Legacy modernisation projects

Sign-off on a legacy replacement is particularly sensitive because the old system is usually still running. The acceptance criteria should define a clear comparison: for each critical process in the existing system, what is the equivalent in the new one, and has it been tested with real operational data?

Agree in advance what happens if a discrepancy is found between the old and new system after sign-off but before the legacy system is decommissioned. A well-structured contract will include a parallel-run period with defined defect-resolution responsibilities, rather than treating sign-off as an immediate and irreversible cutover.

SaaS MVP projects

For a minimum viable product, sign-off scope should be tightly aligned with the MVP definition. Resist the temptation to treat sign-off as the point where every feature on the long-term roadmap gets checked. Instead, confirm that the core value proposition works end to end, that billing and onboarding function as specified, and that the technical foundation is sound enough to support the next phase of development.

Signing off against a demo rather than documented criteria

A polished demonstration is not evidence that acceptance criteria have been met. Suppliers may walk through a happy path that avoids edge cases, error handling and permission boundaries. Always require that sign-off follows a structured test process where the criteria are checked one by one, with results recorded, rather than a presentation where the supplier controls the narrative.

Accepting vague or missing acceptance criteria

If the original specification did not include clear, testable acceptance criteria, the sign-off process will be subjective. "The system should be fast" or "the reporting should be comprehensive" cannot be verified. Before signing off, either agree specific, measurable criteria retrospectively or document exactly what has been delivered and what remains ambiguous, so that both parties understand the limits of what has been accepted.

Confusing sign-off with project completion

Sign-off marks the end of the build phase, not necessarily the end of the engagement. Outstanding items may include minor defects accepted as low priority, infrastructure handover tasks, or warranty-period obligations. The sign-off document should list what is explicitly not included, so there is no assumption that the supplier will continue delivering features without a further agreement.

Not checking asset handover before signing

If your contract states that you own the source code, repository access, infrastructure credentials and third-party licence keys, verify that you actually have them before signing off. Once final payment has been made, your leverage to obtain these assets diminishes significantly. Confirm that you can access the code repository independently, that deployment credentials work, and that any third-party services are in accounts you control.

Key checks before signing off

  • Every acceptance criterion has a recorded pass or a documented, agreed exception
  • Defects classified as accepted have been reviewed by someone with operational responsibility, not just the project manager
  • Data migration has been reconciled against the source, not just checked for obvious errors
  • All user roles have been tested with their actual permissions, not just an admin view
  • Source code, repositories, credentials and documentation are in your possession where agreed
  • The sign-off document clearly states what is out of scope and what outstanding items remain
  • The warranty or defect-fix period, its duration and its response terms are confirmed in writing
  • The support arrangement that begins after sign-off is defined, including what constitutes a support request versus a new feature

Keep the result reproducible

Sign-off is a business decision, not a technical formality. Treat it with the same rigour you would apply to signing a supplier contract, because the consequences of getting it wrong are comparable: unclear ownership, unresolved defects and a weaker position if the relationship with the supplier deteriorates.