🚀 Upgrade Center

The Upgrade Center is your control room for understanding and safely upgrading this TSync installation. It looks at what you have, tells you how healthy it is, builds a step-by-step upgrade plan, lets you rehearse it without changing anything, and — only when you decide — runs it, with backups and rollback ready.

Open it from Setup → Upgrade Center, or from Configuration Center → System.

The golden rule: the Upgrade Center never changes anything on its own. Every action that could change data is something you start, after a backup, and most of it can be dry-run (rehearsed) first with zero changes.

What it tells you at a glance

The overview shows, in plain language:

  • Generation & version — whether this install is legacy, transitional, modern or enterprise, the detected version, and the target.
  • Health — a 0–100 score (it reuses the same health checks as the release gate).
  • Compatibility & risk — can you upgrade safely now, what the risk level is, and why (human-readable drivers like "unknown modules" or "deployed code is ahead of the database").
  • Environment & character set — the detected environment plus a quick utf8mb4 check on the database (the encoding modern TSync expects), so an old utf8-only database is spotted before you upgrade.
  • Next recommended action — one clear sentence on what to do next.

There's also a Run analysis button (saves a snapshot) and an Export for a diagnostics file you can send to support.

The pieces

Detect & analyze

Reads your install's own signals (applied vs deployed migration, modules, environment) and classifies it. Read-only.

Fingerprint

Takes a structural snapshot (tables, modules, option keys, migration state) — metadata only, never your business data, secrets excluded. Capture one before an upgrade and compare later to see exactly what changed. The Support export bundles a redacted version (no secrets, no business rows) to share with support, at one of three redaction levels — basic, strict (the default) or maximum — so you can choose how much detail to share.

Modules, Capabilities & Drift

  • Module inventory — every module, its versions, and whether anything has drifted.
  • Capability inventory — which features (accounting, treasury, REST API, …) are present, partial or off.
  • Drift — a clear list of mismatches (a module on disk but not registered, a missing table, deployed code ahead of the database) with how repairable each one is.
  • Leftover installer folders — see below.

Leftover installer folders

Every time you deploy a new version, the installer folder is renamed rather than deleted (from install to something like install_20260807_014630). That is deliberate: an upgrade that deletes files is an upgrade that can delete the wrong ones. The side effect is that each deploy leaves one more complete copy of the installer sitting on your server — harmless, but each copy still contains a database.sql file.

The Drift page now lists them, showing for each folder its size, how many files it holds, and whether it contains database.sql. Next to each one is a Delete button.

Two things to expect:

  • The most recent leftover is never offered for deletion. It is the copy a rollback would need, so it is marked kept and has no button. Tidying up can never leave you with none.
  • You delete one folder at a time, and each press asks you to confirm. There is no "delete everything" button, and a deletion cannot be undone.

If a folder is marked not writable by the web server, your hosting permissions prevent the deletion — remove it over FTP or ask your host. If a live install folder is present, the page warns you: the admin area stays blocked while it exists, so finish or remove the installation first.

Compatibility & Risk

Turns all of the above into a decision (supported, supported with repair, needs a checkpoint, manual review, blocked) and a risk level with named contributing scores.

"Production ready: NO" now tells you why

The overview used to answer that question with a score — 73/100, 0 blockers, 49 warnings — on the very machine that is production. The verdict was not wrong, it was unusable: it named a number instead of the findings that decided it.

The arithmetic is the whole story. Your score starts at 100 and loses 30 points per blocker and 4 points per client warning, and production asks for 95 or more. Two client warnings — any two — are enough to make an install ineligible.

The reason line now names them: grouped by rule, at most five, with the rest declared as "+N more". Blockers are listed first, because each costs thirty points. The full list of counted findings travels with the health payload, capped at 25, because a list nobody can read is the same as no list.

The threshold and the weights did not change, deliberately. That rule was tightened after an install with health 63 and three critical schema drifts reported itself as production-ready. Loosening a safety gate so a screen reads better is exactly how that defect comes back.

The safe upgrade flow

  1. Plan — the Upgrade Center builds an ordered plan (backup → checks → repairs → database upgrade → validation). Each step shows its risk and whether it can be reversed.
  2. Dry-run — rehearse the whole plan. It reports what would happen and performs zero changes.
  3. Backup — create a verified database backup (it's checked for size and checksum, and stored in a protected folder). High-risk and production upgrades are blocked until a good backup exists. On shared hosting where the built-in backup can't run, you can instead certify an external backup — record the one you took yourself in StackCP, phpMyAdmin or over SSH (method, file name, size, optional checksum and a note). It only records that a verified backup exists so the backup gate is satisfied; it never touches your database and never offers to restore from it.
  4. Approve — a person reviews and approves the plan. For production it's a two-step gate: someone first requests production approval, and a second person with the production permission grants it. Both steps are recorded in the audit log, so the same person can't quietly approve their own production upgrade.
  5. Execute — run the plan, on staging first for anything risky, then production. The Execution Monitor shows each step's progress. Safe steps run; anything that would touch data in a way that isn't fully vetted pauses and waits for you.
  6. Validate — after a run, a completion gate confirms health ≥ 95, zero blockers and zero critical drift, and compares a fresh fingerprint against the pre-upgrade one — flagging anything unexpected.

If something goes wrong

  • Recovery moves a half-finished or drifted install forward to a consistent state (it can re-register a module whose files are present but registration was lost, for example). It runs only the safe automatic repairs and pauses the rest.
  • Rollback returns to a previous state: it reverses safe metadata-level changes, and for schema/data changes it points you at the verified backup. Restore verifies your backup and gives you the exact command — it never overwrites your live database on its own.

For administrators — the command line

Everything is also available from the CLI (the UI and CLI share the same engine):

php index.php tsync lifecycle detect
php index.php tsync lifecycle analyze
php index.php tsync lifecycle fingerprint
php index.php tsync lifecycle drift
php index.php tsync lifecycle compatibility
php index.php tsync lifecycle risk
php index.php tsync lifecycle plan
php index.php tsync lifecycle dry-run
php index.php tsync lifecycle backup
php index.php tsync lifecycle execute --mode staging
php index.php tsync lifecycle recover --mode dry_run
php index.php tsync lifecycle rollback --mode dry_run
php index.php tsync lifecycle restore
php index.php tsync lifecycle validate
php index.php tsync lifecycle status

Flags are space-separated (--mode staging, not --mode=staging).

Good to know

  • Nothing auto-executes — there is no autonomous mode. A human starts every change.
  • Backups first — risky and production upgrades won't start without a verified backup.
  • Everything is audited — analyses, plans, approvals, executions, repairs and rollbacks are all logged.
  • Permissions — viewing, analyzing, approving and executing are separate permissions, so you can let people see the analysis without letting them run an upgrade.

Legacy Bridge

The Upgrade Center doubles as a Legacy Bridge for older v3.4 installs. It does not promise to run every old module as-is — it promises to detect, inventory, protect, migrate or archive your legacy data safely.

The screens you'll use (Setup → Upgrade Center):

  • Legacy Bootstrap — prepares an old install for upgrade: it inventories every module, saves a baseline fingerprint, builds the legacy→modern alias suggestions and the schema bridge. It is completely safe: it never deletes a module and never changes your business data. A "Dry-run" shows what it would do with zero changes. The module alias table is where you confirm how each old module maps to its modern equivalent: for every suggestion you can Approve, Keep separate, or — once approved — Activate the modern module so it takes over. Nothing is activated automatically; you decide each mapping, and every choice is audited.
  • Checkpoints — the ordered steps from a legacy install up to the current release (legacy_bootstrap → foundation steps → current). Each runs only when the previous one is done; the final step never runs early.
  • Migrators — per area you see how much legacy data exists and how it maps to the modern modules. Running a migrator transforms your legacy data into the modern modules — accounting (chart of accounts and journal entries), warehouse, HR, assets, suppliers and production. It is idempotent (running twice never duplicates), non-destructive (your legacy tables stay read-only), and fully audited. It never invents numbers: an unbalanced journal entry, an unmapped row or anything ambiguous is flagged for review, never guessed. Open production orders are paused (never auto-run after the upgrade), and payroll and fiscal history are kept exactly, never recomputed. The Field-mapping intelligence panel shows each area's strategy and, after a run, the count parity (legacy rows vs migrated).
  • Suppliers & purchase documents — the supplier migrator brings across the legacy vendors and their contacts and price catalog, and now also the purchase orders and supplier invoices (with their lines). Each document is attached to the right modern supplier, each invoice is linked to its purchase order, the currency is resolved to its ISO code and the amounts are preserved. Open Migratoare → Detalii furnizori to see, per vendor, the migrated contacts, catalog items, orders and invoices — and a clear note when there are no legacy documents to migrate.
  • Purchased (add-on) client modules — the Upgrade Center now recognizes the common third-party add-ons a client bought for the old install (HR payroll, HR profile, file sharing, feedback, video library and support contact) and can field-map their data into the matching TSync module — TSync HR Payroll, TSync HR Records, File Hub, TSync Project Feedback, TSync Academy and the Omnichannel contact widget. Because these add-ons keep their data in tables with different names, their rows are transformed into the modern tables (values preserved, never recomputed) rather than left behind. After a verified migration the old tables are kept read-only in the archive. Only a genuinely unknown custom module is archived without a migration.
  • Legacy Archive — anything that isn't migrated (a genuinely unknown custom module, or fiscal/payroll history kept exactly as-is) is stored here, read-only, with row counts and a CSV export. Recognized client add-ons (above) are field-migrated first, not just archived. Nothing is ever edited or deleted; you can add notes.

Clean install vs upgrade. If your install is nearly empty, the Upgrade Center will recommend a clean current-release install instead of a heavy legacy migration — you can still run the analysis first.

Important: legacy production upgrades must go through staging first (with a validated backup and approval). The field migration is verified against your real database structure; the final data check runs on your staging copy before production. Nothing runs automatically and a dry-run makes zero changes.