Moving from PowerBuilder to Microsoft .NET

Business Requirements

Business requirements are constantly evolving and your software must not only accommodate this evolution but also match the pace of change. Technology also changes at a hectic pace and software teams that take advantage of the accompanying opportunities find success. Evolving Web Browser and mobile user interfaces and integration technologies such as XML Web Services all represent new opportunities for conveying information to users and disparate systems.

When a significant software asset fails to accommodate new business complexities or cope with new technology at an acceptable pace, we must consider a new foundation for this “legacy”. It is also common to discover an asset’s hardware or software requirements are no longer “a supported platform”. Even more common is the case where an existing system cannot scale to meet increasing volume demands.

When comparing the maintenance costs of a legacy system with the opportunity costs of making an investment in new software, we often come to the conclusion that there are only two choices: redevelop or migrate to a new platform.

Legacy Asset Value

A Legacy asset’s value can be measured in terms of its initial requirements, its design, or its code base or algorithms. Test plans and procedures, and even end user documentation or training materials add to the value of a legacy asset in terms of a basis for migration.

Often a legacy system is considered to be a negative anchor to change. In fact an existing system represents an invaluable point of reference. Developing a new and unprecedented system however, is a more costly and time consuming process. Migrating from an existing point of reference makes the scoping, design, development, testing and overall estimation a more straightforward and process. Notwithstanding, one must be careful not to allow a legacy’s value points act as an anchor, stifling innovation and thinking “outside the box”.

Harvesting a legacy’s value and combining new requirements for a future system will be a key mission statement for a migration process.

Choosing to migrate a legacy asset to a new platform can be a sound business decision. Adopting a new technology must be backed up by a careful plan to migrate people and processes effectively to preserve these intellectual assets as well.

Choosing ObjectSharp Consulting to guide your team through the .NET transition using our proven PowerBuilder User Migration Path will ensure the success.

The PowerBuilder User Migration Path encompasses several processes that are integrated within a software development methodology:

  • Skills Assessment & Training.
  • Analyzing legacy architecture.
  • Designing target architecture.
  • Defining migration plan.
  • Customizing code conversion tools.
  • Development assisted by automatic code conversion.

Analyzing Legacy Architecture

Application architecture typically partitions code into cohesive layers as shown in figure 1.1. This logical separation facilitates greater code reuse in an application and across lines of applications. By decoupling user presentation, business logic, and data access, the system becomes more flexible and resistant to maintenance changes that cascade throughout the system as a result of schematic database changes, new requirements, and the need for alternative user interfaces such as web browsers and mobile devices.
A typical PowerBuilder application architecture is shown in figure 1.2. PowerBuilder applications can have a broad range of architectures and it is a key step to identify these patterns in order to migrate these to the target platform.

Although PowerBuilder, and specifically the DataWindow represented a breakthrough in rapid application development, as you can see from figure 1.2, the inherit architecture of the DataWindow tightly couples user presentation and data access logic. Furthermore, it is all too common that data access logic is dispersed between DataWindows and other PowerBuilder objects just as windows, menu’s and non-visual objects.

Consequently, legacy PowerBuilder applications have not adapted well to increasingly complex business requirements and code reuse with new user interfaces such as web browsers and mobile devices. Innovation in the core PowerBuilder development tool has also been hindered by this architecture.

Designing Target Architecture

Few development tool vendors took the time to rethink development problems in light of the internet during the dotcom era. Instead, most vendors choose to rush piecemeal technologies to market as quickly as possible.

The .NET Framework was built from the ground, rethinking development issues from the ground up. Some of the key challenges have been addressed:

A data access model that is highly scalable to support large web-based applications with 1,000’s of users.
A data model that integrates XML and traditional relational views of data.
An object-oriented web development platform that shares the framework services, languages and rapid application development tools with traditional windows based platforms.
A robust and secure component model that facilitates sharing objects between multiple applications, both windows and web based.

Before undertaking the development of a new .NET Application, an architectural plan must be defined so as to decouple data access, business logic and user interface logic. It is wise to temper these designs with thoughts toward migrating from the legacy system and any considerations for interoperation with legacy systems. Ideally, these requirements should not stifle support for web-based or mobile device interfaces.

Not unlike PowerBuilder, there are many possible architectures that can be defined for a .NET application. A sample .NET architecture diagram is shown in Figure 1.3. In this example architecture, not only is data access logic and business logic decoupled from user interface, but also shared between Windows-based applications and web-based applications. Furthermore, this technology easily allows us to expose our business logic to a wide array of other platforms through industry standard XML Web Services
Defining Migration Plan

Once an understanding of the legacy system’s architecture has been achieved, and an architecture has been defined for the new system, it is possible to begin a migration plan. A technical migration plan will identify how patterns in the legacy system will be implemented under the new architecture. These migration plans identify how data access logic, business logic, and user interfaces will be harvested from the legacy code base and implemented in the new .NET architecture.

A sample scenario is shown in figure 1.4. It is common to subdivide the user presentation, and data access logic from within a DataWindow into decoupled components in the new application. A technique for handling data in a disconnected environment is to use business entities (often implemented with Datasets) and these definitions are also typically derived from DataWindow buffers.
Before committing to a migration plan, the development team will normally engage in a proof of concept to demonstrate the validity of the target architecture and the migration plan. This proof of concept can also act as an initial baseline for future estimates.

For more information about "The .NET Roadmap" and how it can help you smoothly adopt the .NET Platform, please contact Gisele Bourque.

Want to learn more?

Contact our client services manager, Gisele Bourque, at:

Tel: 450-619-9068
Cel: 416-873-0485
Email: gbourque@objectsharp.com