A Neural Log upgrade can affect the application binaries, database schema and configuration. Treat those as one coordinated change for the intended radio group. Publishing this documentation site does not update the application.
Identify the installation#
Record the application version, radio group, database, protected configuration location and current host instance before an upgrade. Each radio group uses its own database. Keep credentials in the installation's protected configuration rather than in notes or documentation.
Use Builds and releases to identify an application artifact. Do not substitute a build from another environment merely because its version number is higher.
Prepare recovery#
Follow Backup and recovery to preserve the group database and managed media together. Confirm that you can restore the backup to a separate environment before replacing a working installation.
Resolve uncertain financial submissions before moving users to another host or browser. A database restore is not a way to retry a payment, invoice or adjustment.
Plan the change#
Review the selected release's database requirements and use its supported upgrade procedure. Do not combine migration scripts from different builds or change feature settings as an incidental part of an upgrade.
For a local development installation, the launcher and its status and stop tools are described in Installation. A production deployment requires the hosting and database procedure selected for that installation.
Check the result#
After the administrator completes the upgrade, confirm the intended application version and radio-group connection. Check sign-in, assigned permissions and access to existing customers, orders, logs and reports before normal work resumes.
Keep the previous build, protected configuration and backup available under the installation's recovery policy. If an upgrade fails, use the prepared recovery procedure; do not improvise changes to saved financial history.