1 September 2026 · 8 min read

How do you update without losing your customisations?

The first update after you customise something is where operators discover whether they kept notes. Files get replaced, changes disappear, and nobody can remember exactly what was different.

Why is this a problem at all?

An update ships new versions of files. If you edited one of those files, your version is replaced. The software does not know your change was deliberate.

The damage varies. A replaced colour is an annoyance. A replaced calculation is a change to what your platform owes people, and it will not announce itself.

Keep a record from day one

A single text file, kept with your notes rather than on the server, listing every change you or a developer made. Four columns is enough:

Two minutes per change, and it turns every future update from an archaeology exercise into a checklist. It is the same discipline as writing a reason on a balance adjustment, described in how to manage user balances.

A safe update sequence

1. Read the changelog and decide whether this release matters to you
2. Take a full backup, files and database, and verify it restores
3. Apply the update to a copy first, with a copy of the database
4. On that copy, walk the money paths: deposit, accrual, withdrawal request, approval
5. Check your customisation list and note which items were overwritten
6. Reapply what is still needed, then repeat the walk
7. Only then apply to the live platform, in a quiet window

Step four is not optional on software that moves money. A visual check tells you the pages load, not that accruals still calculate the same way.

Is every update worth applying?

Security fixes: yes, promptly. This is software holding other people's balances.

Bug fixes affecting what you use: yes, at your convenience.

Features you will not use: optional. Skipping one is fine; skipping every release for two years leaves you on a build nobody supports, which is the position described in why nulled HYIP scripts are a trap, arrived at honestly.

How to read a changelog and judge which is which is in what does a version number tell you about a vendor?

What to do when an update conflicts

Sometimes an update rewrites the exact thing you customised, because the vendor changed the same area. Three options, in order of preference:

• Drop your change: if the new version does the same job, take theirs. One less thing to maintain forever
• Reapply on top: if you still need it, redo it against the new file and update your record with the new date
• Stay on the old version deliberately: a real choice, and only with a note saying why and a date to revisit

How to avoid the problem entirely

Wherever possible, achieve the change through configuration rather than code. A setting survives every update; an edited file does not.

When code is genuinely required, keep it in as few files as possible and prefer additions over edits to existing logic. The boundary between the two is explained in can you change plans and branding without a developer?

Common questions

Question this did not answer? Ask on Telegram. Reader questions get written up first.