Skip to content
LokumTech.

Upgrades and rescue

The update stopped at 20%. What is broken now is your accounting.

We upgrade on a staged copy first, rehearse the rollback before anybody needs it, and then re-check the specific reports that have broken in real releases. If your install is down right now, say so in the first line of the email and we will triage before we quote.

Same-day triageHealth check first

The signatures

You will recognise your own error message here.

This failure pattern has been stable for years and it is still being reported — not a historical bug that a past release closed. That is not a criticism of Akaunting; it is what a self-hosted updater that depends on a live connection to a remote server looks like from the outside.

During the update

  • "Not able to download core" at 20%, and the progress bar never moves again.
  • It reached 60% and stopped. Now every page is a 500.
  • Güncelleme %80'e geldi ve orada kaldı.
  • artisan update:finish exits with code 1 and no useful message.
  • Every page takes forty to fifty seconds and every module reports version 0.0.0.
  • The update ran, and now a table its migration expected does not exist.

After the update

  • 500 Internal Server Error on the Profit and Loss report.
  • Transaction numbers stopped auto-incrementing.
  • Invoice reminders have not gone out since we updated.
  • A module's menu item is still there, but clicking it returns 403.
  • An expense is being counted twice on the Profit and Loss report.
  • We edited a bill and it lost its attachment.

Why it happens

Four mechanisms, and none of them are your fault.

Knowing which one you are in decides whether the fix is ten minutes or a project. Guessing is how a broken install becomes two broken installs.

The updater phones home

Self-hosted Akaunting is not autonomous. The one-click update fetches core and module packages from akaunting.com over a live connection, and the version check expects a specific response shape — one reported failure traced to exactly that, a missing key in the response. When the call fails, the update stops mid-flight. When akaunting.com is unreachable altogether, installs have been documented taking forty to fifty seconds per page with every module reporting version 0.0.0. An air-gapped Akaunting is not a supported configuration, and it is better to know that before you build a policy around it.

Core before apps, always

Akaunting's own version-compatibility policy says users get the module version that was current when their core version shipped, and that authors therefore do not have to keep modules backward compatible. Read the other way round: there is no supported path that upgrades core alone, and none that upgrades an app first. The order is not a preference or a best practice, it is the only sequence the packaging supports.

A migration that half ran

An update that dies partway leaves the database between two schemas. The retry then fails on a constraint for a table that already exists, which is why the second attempt looks like a completely different bug and why people conclude the release is broken. The fix is a manual artisan sequence against a known state — and it is only available if somebody took a snapshot before the first attempt.

2.x to 3.x is not an update

Version 2 runs on PHP 7.4; version 3 needs 8.1 or higher. That is a different server, not a different button. Add the data, the apps that were bought for 2.x, and the reports that have to tie out afterwards, and it is a project with a staging environment and a cutover window. There is a forum thread from someone who treated it as an update and titled it "data seems lost". We quote this only after an assessment.

How we do it

Nothing is attempted on the live install until it has already worked on a copy.

Staged first, rolled back once on purpose, then done for real in a window you pick. The regression pass is a fixed list, because the things that break are a fixed list.

  1. 01

    Triage

    Same day where we can

    Which version you are on, which one you are going to, what apps are installed, whether any core files have been edited, and whether the install is usable at all right now. If it is down, this step is about getting you working — not about the upgrade.

  2. 02

    Stage a copy

    Day 1

    The database and the whole storage directory copied to a separate environment, with outbound access to akaunting.com working, because the updater needs it. This is where the upgrade actually happens for the first time.

  3. 03

    Snapshot, then rehearse the rollback

    Before anything is touched

    A restore point, and then an actual restore into a scratch environment to prove the restore point is real. A backup nobody has restored is a hope, not a plan — and file attachments are the part that usually turns out to be missing.

  4. 04

    Upgrade in order

    Core, then apps

    Core to the target version, then each paid app to the version that shipped alongside it. Where the one-click path fails, the artisan sequence by hand against a known state, with the output kept.

  5. 05

    Regression pass

    The fixed list

    The list beside this, item by item, against your real data on the staged copy. Anything that does not match is fixed or written down before anyone talks about cutover.

  6. 06

    Cutover and a written report

    In a window you choose

    The same upgrade on the live install, in a window you pick, with the rollback ready and rehearsed. Then a report naming the version installed, what changed, what was verified, and what we would watch for the following week.

What we re-check afterwards, every time

  • Profit and Loss — the report that has broken most often, including a 500 after one release and an expense counted twice, fixed in 3.2.1
  • Tax summary totals, compared against the previous period rather than eyeballed
  • Transaction number auto-increment, which stopped between two patch releases
  • Recurring invoices: one test-fired end to end
  • Invoice reminders, which stopped working after 3.1.12
  • Attachments on documents, including one bill edited and saved to prove the file survives the edit
  • Every module's menu item and its permission, because a permission that did not register returns 403
  • PDF output, including Turkish characters in a customer name and an address
  • Cron and mail, re-proven rather than assumed to have survived
  • Opening balances and a trial-balance tie-out, where the client runs Double-Entry
We reply within one business day. Turkish and English.

How it is priced

Per version jump, as a rescue, or never again.

A single jump from a known version to a known version is a knowable scope, so it gets a fixed price. A broken install is not knowable from outside, so it gets triage first. The third option is the one that stops this being an annual event.

Upgrade, one version jump

Quoted after assessment

A known starting version to a known target, staged and verified. Fixed price once we know which apps and which customisations are in play.

  • Rollback rehearsed, not just planned
  • The full regression pass
  • Written report at the end

Rescue

Quoted after assessment

The install is down or half-updated. Triage first, then a fixed price to finish or reverse it, agreed before we touch anything on the live server.

  • Same-day triage where we can
  • Snapshot before any change
  • The cause written down, not just the fix

Never again

Quoted after assessment

The maintenance retainer. Upgrades staged and applied by us on our schedule, with the report arriving whether or not anything went wrong.

  • Tiered by response time
  • Quarterly live restore drill
  • Core and apps kept in step
Invoicing entity: Lokum Tech LLC
2.x to 3.x quoted after an assessment, never sight unseen
A snapshot before any change, without exception
Written scope before any work begins

Starting prices for these packages are being finalised. Ask on a call and we will give you a number, not a range.

Scope

What we take on, and what we will not agree to.

The refusals matter more than the inclusions on this page, because most of them are things a client has asked us for at least once.

We take this on

  • A stuck one-click update, at any percentage
  • "Not able to download core", including on servers with no outbound internet access
  • A 500 after an update, and the half-applied migration underneath it
  • A locked-out admin, or a role assigned to your own account by mistake
  • 2.x to 3.x with the data, run as a project with a staging environment and a cutover window
  • Paid apps and custom modules brought back into step with the new core

We will not

  • Upgrade a production install with no snapshot, even if you ask us to and even if you are in a hurry.
  • Promise that a third-party App Store app has a version compatible with your target core. We check, and sometimes the answer is that it does not.
  • Recover data from a backup that was database-only and never included the storage directory. The files are not in there to recover.
  • Skip the staged copy to save a day. That day is the entire value of the engagement.
  • Guarantee an upgrade path for a customisation made by editing core files. We will tell you what it costs to redo it as a module, which is the only version of that answer worth paying for.

Straight answers

Questions from people mid-upgrade.

The update is stuck right now. What should I do before emailing you?
Stop clicking. Do not retry the update, because a second attempt against a half-migrated database usually produces a new and less informative error. Take a snapshot or a full backup of the database and the storage directory as it stands, even broken — a broken state is a state we can work from. Then write down the version you were on, the version you were going to, and the percentage it stopped at. Those three numbers save an hour.
Why can't you just upgrade core and leave the apps alone?
Because Akaunting's own version-compatibility policy is built the other way round: users get the module version that was current when their core version shipped, and authors are explicitly freed from keeping modules backward compatible. There is no supported core-only path. Core goes first, then each app to its matching version, and an app whose author has stopped shipping is a decision you need to make consciously rather than discover afterwards.
We are on 2.x. Is upgrading worth it?
Usually yes, but not as an update. Version 2 sits on PHP 7.4, which no longer receives security fixes, and version 3 needs 8.1 or higher — so it is a new server, a data migration and a cutover, with the apps bought for 2.x checked one at a time. We quote it after an assessment and never before. If the honest answer for your situation is a clean install plus a data migration, we will say that instead.
Is our data at risk?
The upgrade itself is rehearsed on a copy, so the live data is not touched until the same sequence has already worked once. The real risk on this kind of job is not the upgrade, it is discovering at rollback time that the backup was database-only and the attachments were never in it. That is why the restore is performed, in front of you, before the upgrade rather than after it.
How long does a version jump take?
For a single jump on a straightforward install: a day or two of work spread over a few days, most of it waiting on your window rather than on us. What moves the number is the count of paid apps, whether anyone has edited core files, and whether there are custom modules to re-verify. The assessment gives you a figure rather than a range, and that figure is what we hold to.
We are on 3.1.x and everything looks fine. Why bother?
Because "looks fine" and "is producing correct numbers" are different claims. Release 3.2.1 fixed an expense being counted twice on the Profit and Loss report; before that fix, an install could look completely healthy while overstating expenses. There is also a thousand-separator parsing fix in the same release, which is the bug behind years of Turkish users being unable to enter a price like 100,50. If you are on an older release, you still have both.

Every good build starts with a conversation.

Tell us the process that hurts. We will tell you honestly whether we are the right studio for it — and if we are not, who is.

Book a 30-minute callWho does the work