When One Module Upgrades

Modules upgrade independently. Joins do not, and nobody tells the join.

What an upgrade can change

The export format, by adding a column, renaming one, or changing a date format.

Default settings, including calculations that arrive enabled.

Field lengths and identifier formats.

API behaviour, including what an error looks like.

Permissions, so an integration account loses access it had.

None of these is announced as a breaking change, because to the vendor it is not one.

The pre-upgrade check

List which joins touch the upgrading module.

Read the release notes specifically for format, defaults and permissions — not for features.

Ask the vendor whether the export schema changed, in writing.

Confirm the integration account still has what it needs.

The post-upgrade check

Run the reconciliation immediately, not at month end.

Compare record counts on the first transfer.

Check the rule register: did any calculation get enabled that was off?

Test one person end to end through the chain.

Twenty minutes, and it catches almost everything that would otherwise surface in a pay run.

Coordinating across modules

In a suite the vendor coordinates, which is most of what a suite is for.

In a best-of-breed estate someone has to, and that someone is the chain owner.

Maintain a calendar of each vendor's release schedule, so an upgrade is not a surprise.

And never let two modules upgrade in the same week, because then a broken join has two candidate causes.

Contract terms worth having

Notification before changes to export formats, defaults or API behaviour.

A preview or sandbox where the new version can be tested against your integration.

Version support windows, so you are not forced to upgrade on the vendor's schedule during a peak.

Ask for these at procurement, when they are a negotiating point.

The failure that keeps happening

An upgrade goes in, the transfer runs, the format has changed, the import accepts it anyway and produces plausible wrong data.

Which is caught by the reconciliation and by nothing else, because both ends report success.

That is the argument for reconciling on a schedule rather than when something looks wrong.

Never upgrade two modules in one week

A scheduling rule that halves every future investigation.

A broken join after two simultaneous upgrades has two candidate causes.

After one, it has a suspect.

Maintain a calendar of each vendor's release schedule so this is a choice rather than a coincidence, and so an upgrade during a peak is noticed before it happens.

Follow the difficult record

Use the connected-work reference to frame one representative case. The useful evidence is the record created when a value is corrected, approved and exported.

Independent reference

For a thematic point of reference, see GitHub Docs. Use this established source as an outside check before turning the principle into a system rule.