Guide to taking over Magic XPA system without an orderly handover

Workflow: Taking Over a Magic / uniPaaS / XPA System Without a Handover

Step 1: Avoiding Misunderstandings in the Process

Before touching the keyboard, you must establish “facts on the ground”:

  • Work with Full Transparency: Remote connections should only be performed while the client is watching the screen.

  • Document Current Status: Ask the client to demonstrate one core process that works and one process that is currently broken.

Step 2: Environment Audit

Identify the system’s technological components:

Parameter What to check? Magic Emphasis
Engine Version xpa, uniPaaS, V9, V10? Affects memory management and INI files.
Database MSSQL, Oracle, Pervasive? Check the Gateway in the system settings.
Runtime Mode Single User / Multi-User Is an Enterprise Server / Broker being used?
Operating System Win Server 2012/2019/2022? Check for version compatibility.
Language Hebrew (Visual/Logical) What is the system’s primary encoding/language?

Step 3: Verifying Backups and Data Integrity

Do not take the words “we have a backup” at face value.

  • Consult the IT/System Admin: Verify if the backup is file-level or a full Server Snapshot.

  • Backup Type: Is the DB backed up separately (SQL Backup)?

  • Integrity Check: Ask the client to run a simple query or report to ensure the system is currently “live,” not locked, and functional.

Step 4: The “Time Capsule” (Self-Backup)

Before making any changes, create a local copy for yourself. This is critical:

  • Logging Dates: Document the Modified Date of the Runtime files (.ecf / .cab) and the Source files (.edp / XMLs) before copying them to your machine.

  • Export Files: Pull a copy of the Magic.ini file, the source files, and the runtime files.

Step 5: The Sanity Build (Source Vitality Check)

This is the most critical stage: Is the source code you have actually what is running at the client site?

  • Create a Test Object: Inside the development environment, create a new program (at the bottom of the list) with a blank command or a “Verify.”

  • Use Menus: Do not use keyboard shortcuts (F6, F7) for fear of different key-mappings. Use the Options menu.

  • Write Test: Close and reopen the Studio. If the program disappeared, the system is set to Read-Only, or there are no write permissions. You cannot modify the system until this is resolved.

Step 6: Archaeological Investigation (Information Gathering)

If there is any lead on the person who previously worked on the system, these are the mandatory questions:

  • Compilation Integrity: Does the current source compile without errors?

  • Open Developments: Are there programs in a “Check-out” state or “half-baked” code in the source?

  • Automations: Are there Batch Tasks running in the background (Task Scheduler) that might be affected by a version update? Are there things in the Main Program that run under specific conditions that might trigger unwanted updates if activated accidentally?

  • Deployment Process: How is a version usually deployed here? (Replacing an ECF, running a script, etc.)

Step 7: Risk Management and Sandboxing

The golden rule: Never develop directly on Production.

  • Local Copy: Copy the entire environment (including the DB, if possible) to your local machine.

  • Delta Check: Compare the file size of the new Build you created (from the original source, before your changes) against the original runtime file. Any discrepancy in size indicates a mismatch between the source and the runtime.

Step 8: Deep Dive

Before performing any change requested by the client:

  • Check the Main Program: In Magic, this program can contain logic that affects the entire system (Events, opening conditions). You must understand it.

  • Program Dates: Review the Task List. Programs with unusual dates (newer than the Runtime) are “suspects”—likely unfinished developments.

Step 9: The Canary Run (Controlled Launch)

After making a small change:

  1. Replace the runtime version.

  2. Let the system run for a week under normal load.

  3. Only after a week of “industrial silence” (stability) should you begin significant development.

Important Note for the Developer:

The above points are recommendations only. The responsibility for deciding what to do and how to do it—and the results of those decisions—lies solely with the developer in each specific case. There may be errors in this guide or mismatches for specific scenarios.

Additional Note:

Although the text above contains nine steps and a lot of detail, taking over a system without a handover should generally not take more than a few hours.

Good luck!