Reason #6: Magic v5-8 are not object-oriented or component friendly and C# and Java won’t help (but Magic xpa will).

20 Reasons to Migrate Magic eDeveloper, uniPaaS and Magic xpa to .NET by Upgrading Rather than Converting

Reason #6: Magic v5-8 are not object-oriented or component friendly and C# and Java won’t help (but Magic xpa will).

Some conversion vendors offering Magic  to .NET conversion won’t even admit that Magic v5-8, Magic eDeveloper, uniPaaS and Magic xpa don’t need to be converted to C# in order to become 100% .NET based applications. An Upgrade to the latest version of Magic xpa will take advantage of the .NET platform without locking you into a non-platform based language like C# that requires large programming teams.

Thousands of companies worldwide have made a clear commitment to an extended life for their Magic applications, as they represent solid, comprehensive, core business functionality within their companies. These decisions are congruent with the key Val IT principle that “IT-enabled investments will be managed through their full economic life cycle.” (IT Governance Institute, The Val IT Framework).

In this series of articles, we will review 10 reasons to upgrade rather than convert. Let’s look at reason number one.

Reason #6: Magic v5-8 are not object-oriented or component friendly and C# and Java won’t help (but Magic xpa will).

By upgrading, you gain a platform with built-in component resource handling capabilities and maximum compatibility with your existing application logic. The Composite Resource Repository (CRR) in the Magic xpa Studio contains all of your objects for making calls to external components.

From the Magic xpa CRR, you can:

·         Reload a component interface or load a new component by selecting Load/Reload Components from the Options menu. When an ECI file is loaded or reloaded, Magic xpa checks the component type defined in the interface and changes the Type property of the CRR accordingly. This would require extra manual programming in C# or Java.

·         Invoke a wizard that will both create a component that connects to an external resource and create the component’s interface. This would require extra manual programming in C# or Java.

·         See the component interface by zooming from the Name column.

·         Assign rights to a component. This would require extra manual programming in C# or Java.

·         Use the Locate mechanism to locate a specific component type. This would require extra manual programming in C# or Java.

If you convert older Magic applications to C# or Java code instead of upgrading, your business logic is stranded or isolated and has no access to the Composite Resource Repository. Regardless of whether you currently deploy Magic v5, Magic v6, Magic v7 or Magic v8, or even a later eDeveloper of uniPaaS application that has not yet taken advantage of the Composite Resource Repository, upgrading is a more efficient way to leverage your Magic application and modernize your application. All development becomes manual in C# and Java and loses the significant inherent advantages of platform based computing. For additional information on how an upgrade is superior to Magic to .NET conversion please convert here.