When an update notification arrives for a business running Logo GO or Logo Tiger, two opposite reactions are common: postponing the update indefinitely with a “let's not touch it for now,” or applying it the moment the notification appears, without any preparation. Both come from the same place — the fear that an update might break something. That fear is not unfounded. But it is manageable. With the right preparation, an update becomes a planned operation rather than a surprise.
Neither postpone the update nor rush into it
Postponing updates indefinitely has a concrete cost: new versions typically carry fixes for known issues and changes that keep the product aligned with current regulations (tax, e-Transformation, and the like). The older the version, the further it drifts from both those fixes and regulatory alignment. On the other hand, applying an update the moment it arrives, without preparation, is its own risk: an update run without a backup and without a clear scope can take away the option to roll back if something goes wrong. The right approach is to apply the update at a planned time, once a defined preparation list has been completed.
The pre-update checklist
The items below are not about the update steps themselves — those vary by product and by version, so they are not described here. Instead, this lists the checks that should be in place beforehand, regardless of who performs the update:
- A full database backup should be taken, and it should be verified as genuinely restorable — meaning actually restored in a separate environment. The existence of a backup file alone is not enough; a backup that has never been restored is not a guarantee.
- The current version and the target version number should be noted. Knowing exactly what was upgraded from and to is the first step if an issue arises.
- LEM (Logo Enterprise Membership) status should be checked. LEM is the annual membership that grants the right to move to the target version and to regulatory updates; whether it is current should be confirmed before updating.
- Custom reports, forms, vouchers, integrations, and any custom development should be listed. These are the items that will need to be checked one by one after the update.
- Whether third-party integrations (e-Transformation, banking, e-commerce, WMS, and similar) will keep working correctly with the target version should be confirmed.
- The number of users on the system and who will be logging in, and when, during and after the update should be clarified; no one should be in the system at the moment of the update.
- A rollback plan should be defined in advance for if something goes wrong: under what conditions to revert to the previous version or the backup, and who makes that call.
Timing: don't update during critical periods
Even with the checklist above complete, when the update happens is a separate source of risk. Period-end closing, an annual or periodic inventory count, a payroll period, or the run-up to a critical delivery date are not good times for an update. The reason is simple: a disruption during these periods doesn't affect a small slice of daily operations — it affects the whole period, at a time when workload is already high and there is less room to deal with a problem. Updates should be scheduled for a relatively quiet stretch of operations, one where there is enough time to respond if something goes wrong.
Post-update verification
The job isn't done once the update finishes — it still needs to be confirmed that the system works as expected. That verification should happen with test records first, not live data. The main areas to check:
- Invoice issuance and e-Transformation submission (e-Invoice, e-Archive, e-Dispatch Note) should be tried with a test record
- Inventory movements and any warehouse/WMS integration should be checked for correct behavior
- Balances on account and finance screens should be compared against their pre-update state
- The listed custom reports and forms should be re-run to confirm their results haven't changed
- User permissions and module access should be checked to confirm they match the pre-update state
Who should do this
An update should not be left to one person's initiative. The backup and the technical execution should be handled by someone with the technical knowledge to do it; which reports, integrations, and processes are critical should be identified together with the accounting, sales, or operations teams that use them daily. Regardless of who ends up applying the update — an in-house team or an outside technical partner — having the checklist above fully completed is what largely determines the outcome.