Updating 6amTech scripts without losing your customisations

6amTech releases updates regularly, with new features, bug fixes, security patches and compatibility changes for new Android and iOS versions. Skipping them for too long leaves you on an old Flutter SDK, a deprecated Firebase API or a target API level Google won't accept. Taking them carelessly overwrites your customisations. Here's the workflow we use to update client platforms safely.

The core problem

A 6amTech update comes as a new set of files, not as a patch to your code. If you've changed the admin panel or apps (and every rebranded platform has), copying the new files over your installation erases those changes. The answer is to treat the vendor release as one branch and your customisations as another, then merge them deliberately.

Step 1: get your project into Git, today

If your platform isn't under version control, start now:

1. Create a private repository for each part: admin panel and each app.
2. Commit the original vendor version you started from, unmodified, on a branch called vendor.
3. Commit your current customised code on main on top of it.

If you no longer have the original version, download it from CodeCanyon if it's still available, or reconstruct it as closely as you can. This baseline is what makes every future update manageable.

Step 2: read the changelog and the update docs

Before downloading anything, read the release notes and the update instructions for the new version. Look for:

• Required PHP, MySQL or Flutter versions. Server changes may come before the code update.
• Database migrations or update scripts.
• Changes to configuration, such as new environment variables, new API keys or Firebase changes.
• Add-on compatibility. Add-ons often need updating at the same time.

Step 3: diff the vendor release

Put the new vendor release on the vendor branch and commit it. Now Git shows you exactly what 6amTech changed between versions. Merge vendor into a new branch from main. Conflicts appear only where both 6amTech and you changed the same lines, and that's where your attention goes.

This is also why a branding record matters. Files like theme colours, app names and package IDs conflict on almost every update.

Step 4: update on staging, never on live

Set up a staging copy:

1. Clone the live server, or create a similar one.
2. Copy the live database to it. Anonymise customer data if others will test.
3. Deploy the merged code.
4. Run the update steps from the docs, including migrations or the update wizard.

Then test the flows that make you money: register, browse, order or book, pay, accept, deliver, refund. Test with the updated apps against the staging server.

Step 5: rebuild and test the apps

App updates usually need:

• The Flutter SDK version the new release specifies.
• flutter pub get and fixing any breaking dependency changes.
• Re-checking package names, Firebase config files and Maps keys, which merges can quietly revert.
• Raising the version number and build number.
• Test builds on real Android and iOS devices.

Step 6: plan the live release

• Back up the live database and files immediately before updating, and confirm the backup restores.
• Update at your lowest-traffic time.
• Use maintenance mode during the database update.
• Deploy the backend first, then submit the apps. Old app versions usually keep working with the updated backend for a while, but test this on staging.
• Keep the previous release ready so you can roll back quickly.

Step 7: keep customisations update-friendly

Going forward, reduce future conflicts:

• Put custom features in new files and classes where possible, instead of editing vendor files throughout.
• Keep a customisation log listing each feature, the files it touches and why.
• Avoid editing vendor database tables. Add new tables or columns through your own migrations.
• Update regularly. Jumping five versions at once is much harder than one at a time.

How often to update

At minimum, update when there's a security fix, when a store requirement forces it (for example a new Android target API level), or when Firebase or another key service deprecates something. Otherwise, a planned update every few releases keeps the work small.

A quick update checklist

Before every live update, confirm:

• The changelog and update docs have been read, and server requirements are met.
• The merge is complete, and conflicts have been reviewed by someone who knows the customisations.
• Staging passed the full order, booking or trip cycle with the new app builds.
• A fresh backup has been taken and its restore tested.
• Maintenance mode, the deployment and the rollback steps are written down.

How we help

Our Care plan follows this exact process: version control, staging, merge, test and release, so you get 6amTech's improvements without losing what you've built. Read more in the Packages section and see the platforms we maintain in our solutions.