Skip to content
Timesheet Systems

All notes  /  06 · Operations

When the Vendor Updates

Hosted software changes underneath you. What to check after each release, and why new features arriving enabled is the risk worth watching.

Procedure

A hosted product is upgraded on the vendor's schedule, not yours. The work is not preventing that; it is noticing what changed.

What can change without asking you

New features, frequently enabled by default. This is how monitoring capability appears in a system bought without it.

Default settings on new accounts.

Calculation behaviour, where a fix to someone else's bug changes your totals.

Export formats, which breaks the payroll integration.

API behaviour, including validation that was previously lenient.

Interface changes that invalidate your training materials.

The post-release check

Twenty minutes, after every release, by the named owner.

Read the release notes, specifically for anything about capture, defaults or calculation.

List the capture features and their state. Compare against the configuration recorded at go-live.

Run one period's export in a sandbox and diff it against the previous format.

Recalculate a known period and compare the totals. A change here is the one that reaches payslips.

Check that your configured rules survived.

The exclusions specifically

If you excluded screen capture, activity scoring or idle deduction at procurement, re-verify after each release.

A feature added in an upgrade is exactly the case the contract term about notification was for. Use it.

Record the check result, because "monitoring was never enabled" is a claim you may need to support with dates.

Sandbox environments

You need one, and some vendors charge for it.

Ask for it in the contract rather than at the first upgrade.

Refreshed from production periodically, or it stops representing anything.

Used for the export diff and the recalculation check before the release reaches production, where the vendor offers a preview window.

When a release breaks something

Report it with the specific comparison, not a description. A diff of two exports gets a faster response than a paragraph.

Check whether it affected a closed period. If a recalculation changed historical figures, that is a correction with consequences for people already paid.

Keep the pre-release export, which is why the exported file belongs with the period record.

Log it, because a pattern of releases breaking the same integration is a renewal conversation.

What to ask for in the contract

Notification before feature changes that alter what the system observes or how it calculates.

A preview or sandbox window before releases reach production.

A stated export format with versioning, so a change is a deliberate event rather than a surprise.

Record what you checked

The evidence that turns a claim into a fact.

Date, release version, features checked, state found.

Especially the capture features, where your position may need supporting with dates.

Kept with the configuration record from go-live, so the two can be compared.

Five minutes to write, and it is the difference between "monitoring was never enabled" as an assertion and as a documented sequence of checks.

Connected products widen the change surface

Review release effects beyond the core application. Published time tracking integrations provide a useful inventory for deciding which connected workflows need regression tests.