--- title: Upgrade Center β€” analyze, plan and safely upgrade your TSync installation description: A friendly guide to the TSync Upgrade Center (TLMP). See what version you're on and how healthy it is, get a safe upgrade plan, take a backup, dry-run it, and β€” only when you choose β€” execute, recover or roll back. Nothing ever runs automatically. product: TSync Intelligence 11.3.6 language: en canonical: https://docs.tsync.pro/modules/tsync-lifecycle/ source: https://docs.tsync.pro/llms.txt --- # πŸš€ 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.