Upgrading EDGEBIC Safely

Upgrade EDGEBIC safely with three steps: back up the database first, install the new version and launch it once so the database updates its own internal structure, then verify a known schedule before the team logs in. In EDGEBIC by User Solutions the database structure updates itself automatically on the first launch of a new version, so the upgrade is not a manual migration project. The care is in the order of operations, and the single habit that makes it safe is the backup you take before you start.

This post is the upgrade routine for an administrator. For the full reference behind every control here, read the EDGEBIC admin guide. It names controls that live in the DataSource tab and the recovery window, never any internal path.

Back Up Before You Touch Anything

A database structure update is one of the operations without a built-in undo, which puts it in the same category as a data clear or a provider switch: the moment to make a backup is before the operation, not after. Take the one-click export from the DataSource tab for the local single-file database, and for a shared SQL Server database confirm IT's nightly rotation has a fresh copy and take your own export as well.

The reason to be deliberate here is not that an upgrade is expected to lose data. It is that a structure update, like any operation without an undo, deserves the cheapest insurance available. An export costs one click. Restoring from it after an interrupted install costs nothing but a few minutes. Skipping it costs a rebuild if the one-in-a-hundred power loss lands mid-update.

Let the Database Update Itself

Once the new version is installed and you launch it, the database updates its own internal structure to match the new version. This is automatic and it works the same way for the local single-file database and a shared SQL Server database. There is no separate migration tool to run and nothing to edit by hand.

Your data is preserved through this. Schedules, work centers, products, customers, and history all stay in place; what changes is the database's internal structure, not its contents. The update is about making the existing data compatible with the new version, so the plant you built is the plant you keep.

For a shared install, one detail matters: the database structure updates a single time against the shared database, not once per user. Update the application on the administrator's machine and launch it first, so that first launch performs the one update. Every other planner then updates their own application and connects to the same, already-updated database. That is why a team upgrade is one launch of downtime rather than one per seat.

Verify Before the Team Connects

An upgrade is not finished when the application opens. It is finished when you have confirmed it behaves. Open a known job, look at its schedule, and confirm the numbers match what you saw before the upgrade. Run a small reschedule and check the result. If you use scheduled integrations, glance at the run history to confirm the next run is healthy.

Doing this on the administrator's machine before the wider team connects means any surprise surfaces on one login, not twenty. It is the same principle as updating the shared database once: concentrate the risk on the controlled first launch, then let everyone else follow onto a verified system.

When the Recovery Window Appears

If a launch after an upgrade opens the recovery window instead of the main application, treat it as a guided fix rather than a failure. The window shows the error with expandable details and offers four actions.

• Repair the database rebuilds the internal version bookkeeping for a database whose structure is already current, without changing your data. After an interrupted upgrade, this is often the right button.
• The embedded data-source editor lets you correct the connection if the new version pointed at the wrong database.
• Reset to the default local database gives you a clean starting point if you then restore your pre-upgrade export.
• Retry re-attempts the same connection, useful when a shared server was simply still restarting.

Startup errors also write to a dedicated log, so if none of the four actions resolves it, that file is what support wants. The broader walkthrough lives in database connection troubleshooting.

The Upgrade in Five Lines

Put together, the safe upgrade is short.

None of it is heavy, and none of it is guesswork. The database does the structural work; you provide the order and the backup. For the ongoing care that keeps the database dependable between upgrades, read keeping the EDGEBIC database healthy over time, and for the wider context of why a stable scheduling system matters, see what production scheduling is. The full administrator reference is always the EDGEBIC admin guide.