Safe update of a Bitrix project. Principle: first conflict analysis and backup, then apply, always on a copy/stage before prod. Orchestrator gates apply.
Environment
- "live Bitrix" → you can read versions, check updates, apply; "files only" → offline conflict analysis (core modifications, /local, versions).
Full cycle → recipes (../../shared/kb/recipes/update/)
- version introspection (core + modules + Marketplace apps) →
update/01-introspect-versions.md - finding available updates (SiteUpdate + Marketplace) →
update/02-find-updates.md - conflict and risk analysis (core edits, /local overrides, custom modules, PHP/DBMS, license) →
update/03-conflict-analysis.md - apply (backup → core → modules → solutions) →
update/04-apply-update.md - post-check and rollback →
update/05-rollback-verify.md - diagnosing update errors / symptom → fix (php.ini requirements, incomplete update, error codes) →
update/06-troubleshooting.md - encoding migration cp1251 → UTF-8 (DB, files, serialized data, search) →
update/07-utf8-migration.md - updating Marketplace / partner / own module solutions →
update/08-marketplace-solutions.md - safe test update on a copy ("Development installation", ERROR_WRONG_CODE, key protection) →
update/09-staging-clone-safety.md - core version transitions (SiteUpdate, order core→modules→solutions, transition between majors 24→25→26, license/coupon) →
update/10-version-transitions.md
Tools
../../shared/scripts/check-conventions.sh <проект>— will help in analysis (core modifications, code outside /local).- Backup/restore and migrations between environments — sub-skill
1c-bitrix-cms-setup.
⚠️ Key points
An update is a potentially destructive operation: a fresh backup is required, run on a copy/stage, check compatibility and license (active update coupon) before applying to prod.
Completion
After the update: the site comes up, check-conventions without [FAIL], key scenarios work; otherwise — rollback.