Upgrade to MSE's uniPaaS

Many existing Magic users are at a cross roads: upgrade or migrate.

We are here to support you, either way. Our conversion expertise is also valuable when you upgrade to uniPaaS. There are three conversion steps required when you upgrade from Magic eDeveloper to Magic uniPaaS:

  1. MSE's v9converter - a utility provided by MSE to import a V9 application export
  2. MSE's RM Converter - a utility provided by MSE to remove the Record Main Compatible
  3. Manual conversion

Step 1: MSE's v9converter

The v9converter creates a uniPaaS application. Although certain functions are no longer supported and there are some performance issues, mainly related to batch tasks, for most applications the new application will function as the V9 application did. If that is not the case for your application (for example if you have a lot of performance critical batch tasks, your SQL code is not optimized, or your app relies heavily on functions that are no longer supported) then, depending on the size of your application it may be appropriate to call upon our conversion expertise to address the issues that resulted from this phase with a small custom converter utility to assist in the upgrade to uniPaaS.

Step 2: MSE's RM Converter

The RM Converter tries to remove the Record Main Compatible handler that was created in step 1. Each task that had business logic in the Record Main will result in a task with a Record Main Compatible in uniPaaS after step 1. While the application will function with the Record Main Compatible handlers in place, sooner or later you will need to remove all the Record Main Compatible handlers. Initially you will find that working around the limitations, which the Record Main Compatible handler imposes in uniPaaS, forces you to remove the handler as soon as any serious maintenance work is to be done. You will also want to remove the Record Main Compatible handlers when you want to take advantage of most of the new uniPaaS functionality. And finally because the next major release will no longer support the Record Main Compatible. 

The problem is that the RM engine behavior in Magic V9 is at times difficult and for some Record Main code even impossible to duplicate with just an event driven paradigm. The result is that MSE cannot guarantee that your application will behave the same as it did in V9.

While there are several known and documented issues of very common scenarios the RM Converter cannot  properly convert without creating a certain or a possible change in behavior, there are also several undocumented issues in which the converter creates either a certain or a possible change in behavior. 

While M2J can guarantee and demonstrate proper conversions to Java (even if you used business logic in your Magic Record Main, MSE indicates it will not be able to guarantee proper Record Main conversion to uniPaaS' event driven paradigm. The problem for MSE's RM Converter to uniPaaS is that the target event-driven-only-paradigm is not a superset of the capabilities the Magic V9 engine environment offered.

Check out this short uniPaaS RM Converter clip that demonstrates the RM Converter and a few of the challenges of moving to uniPaaS' event driven paradigm.

* As per the uniPaaS RM Converter manual.

Another problem we noticed using the RM Converter is that the RM Converter log file does not reflect the change in application behavior. The log only identifies the changes that were made to the code (we can however also demonstrate that it can remove code inadvertently and report that no changes were made).  All this makes it virtually impossible to find changes in behavior. To address this we provide a service that identifies tasks and handlers in tasks that require manual conversion follow up for the documented problems and the undocumented problems we have identified to date.

Step 3: Manual Conversion

After identifying all the conversion problems, it is time to rewrite your uniPaaS code to correct application logic errors that resulted from the RM conversion. This requires Magic expertise and subject matter expertise. While we can provide Magic expertise, we will need access to your in-house subject matter expertise to properly correct application logic errors that resulted from the RM Converter.


The upgrade to uniPaaS is fairly straight forward for Magic V9 applications that were already completely event driven in V9 and had no (or very little) Record Main logic.  For most applications, especially those that evolved from earlier versions of Magic, the upgrade to uniPaaS will prove to be the most challenging upgrade in MSE's history due to the challenge of having to remove the Record Main:

  1. The known and documented problems that will cause changes in behavior are very common throughout most tasks;
  2. The RM Converter log does not identify application logic behavior changes;
  3. The RM Converter log does not always correctly identify code changes;
  4. The behavior changes can be very difficult to find with standard QA tests.

M2J provides custom services to address these challenges. Please contact us for us to better understand your specific situation and to determine how to best help you leverage your investment in Magic.