Platform or vendor support ending Archives

Challenges of PowerBuilder modernization

PowerBuilder is best known for its rapid application development (RAD) capabilities, particularly for building data-driven client/server business applications. It’s estimated that billions of lines of PowerBuilder code are running applications in North America alone, let alone globally.

PowerBuilder is considered to be a 4GL language. Key features of 4GL are a higher level of programming abstraction that is then used to generate the code into a lower-level language such as C or C++ and extensive components embedded into the language itself or its built-in system library. PowerBuilder is more of the latter than the former. Its WYSIWYG IDE with its event-driven programming model and all-in-one DataWindow presentation with powerful yet simplified data access CRUD capability, including sorting, filtering, computed fields, reporting, and other capabilities, is what gave it its claim to fame in its heyday.

Today, companies are looking to transform these applications to web and cloud environments to reap the benefits of their ubiquity, scalability, and global adoption. But what are the actual challenges of taking working, bespoke production applications written in PowerBuilder and transforming them into modern stateless microfrontends and microservices web architectures deployed in secure and scalable cloud platforms? Our modernization experts share some of the critical technical challenges teams face when undertaking such an endeavor.

Challenges modernizing PowerBuilder applications

Architectural differences

Generally speaking, PowerBuilder applications use a client-server architecture where the client handles much of the business logic and the server manages database access. Web applications, on the other hand, follow a more distributed architecture, often involving web servers, application servers, and browser-based web clients.

Splitting a monolith, especially a client-server, standalone, stateful monolith, into a web architecture is not for the lighthearted. Key challenges are:

Refactoring and decoupling presentation layout and logic from the underlying business model and logic.
Extracting application services into the web server tier and replacing direct access with REST calls.
Identifying interdependencies, interwoven user interfaces, and business logic and properly splitting it to work in the web tier.
Removing dependencies on stateful data access, such as open cursors and long transactions.
Last but not least, re-implementing the decades-old reliable software in new, and often multiple, new modern programming languages.

General code migration challenges

Modern web applications often use frameworks such as Angular, React, or Vue.js. Integrating the PowerBuilder business logic and data access layers with these frameworks requires significant refactoring and a very heavy lift in the absence of automation and refactoring tools. While dealing with a single PowerBuilder language, often target architecture requires multiple languages – JavaScript on the client and/or Java or C# on the server. In addition, PowerBuilder uses its own scripting language, providing additional capabilities for manipulating data retrieved from databases that may require a complete redo or an equivalent custom interpreter that will implement the equivalent semantics and functionality on the web.

Type safety and validation

PowerBuilder’s dynamic data typing allows flexibility but can lead to runtime errors. Migrating to a statically typed language involves enforcing type safety throughout the application, requiring an upfront investment in defining interfaces, types, and classes for consistent data handling and error prevention. Validation is often embedded inside the DataWindow objects and must be shifted to a mid-tier or form validation in the browser.

User Interface (UI) transition

PowerBuilder applications use a desktop-style UI with windows and dialogs that don’t naturally translate to a reactive web layout, especially for DataWindow 4GL-like components. Web frontend frameworks such as React offer rich UI components. Still, those components do not have all the equivalent properties and presentation semantics offered by the PowerBuilder’s rich set of controls and visual components and certainly do not provide a DataWindow equivalent functionality. If a like-for-like outcome is chosen, an initial step of modernizing a PowerBuilder application will require an equivalent DataWindow compatibility component framework to be implemented in the target web UI framework. For a more comprehensive modernization with the objective of achieving a native web UI/UX target, a more granular approach is necessary to break down the underlying data window-dependent behavior into separate independent pieces of display/presentation behavior, corresponding data access and data binding, and reporting capabilities.

Data access

The DataWindow is the PowerBuilder superpower. Its abstraction includes presentation (drawing and displaying forms that can have both simple and complex widgets), data access that includes SQL or stored procedure invocation, data binding, and transactions. A more comprehensive approach is needed to achieve functional equivalence on the web target with a smart, well-integrated compatibility library that sits on top of existing frameworks such as React or Angular. Adapting the data access layer to work with web technologies involves changes in how database connections are managed. The main challenge is the proverbial “thin-client” architecture, which implies statelessness. It’s not just that we are using different technologies for session management, connection pooling, etc.; the underlying transformation of the monolith into a microservices and microfrontends web and cloud architecture is where the real challenge lies.

Session management paradigm shift

PowerBuilder applications often rely on the session state maintained within the client application. In a modern web application, managing the client state requires technologies like Redux or another persistent data store on the browser side. Moving from a primarily client-side state management model to a distributed client-server architecture requires careful consideration of data synchronization. Depending on the application’s needs, data consistency and responsiveness are often achieved using REST APIs or WebSockets.

Performance

Whether the application is modernized for the web or built ground up for the web, it comes with the web territory of potential network latency in user response times and scalability depending on the demands of the underlying application profile. When modernizing a client-server architecture to the web, there is also the risk of potential consequential database “chattiness.” Once the application has achieved functional equivalence, attention must be placed on performance, overall application deployment, and scalability.

Security

There are differences in security practices for client-server applications and web applications. One of the most challenging parts of a PowerBuilder modernization to the web is extracting the application logic and, most importantly, the data access in the form of SQL and stored procedure calls to a web service layer. Once successfully split, other security layers, such as secure authentication (e.g., MFA, SSO), authorization protocols (e.g., OAuth, SAML, JWT), and data encryption and secure transmission (e.g., HTTPS), become more straightforward.

Overcoming these challenges

Addressing these challenges requires careful planning and a comprehensive modernization strategy. A phased approach to modernizing the application while maintaining its core functionality and user experience is often the best. At Synchrony, we go by the slogan, “don’t let perfection stand in the way of progress.” With our in-house advanced analytical tools, powered by code refactoring and code generation automation, we help streamline an otherwise very complex undertaking by simplifying its inherent complexity, reducing the risks associated with group-up overhauls, and ensuring that modernizations achieve functional equivalence and are completed at a fraction of cost and time with the absence of advanced automation.

Contact us to discuss your specific modernization needs or if you’d like to learn more about our PowerBuilder modernization experience and expertise.

5 legacy system cybersecurity risks in 2025

Legacy systems, the reliable workhorses of the past, can become security nightmares in today’s ever-evolving threat landscape. While they may keep critical functions running smoothly, their outdated technology and lack of modern security features create vulnerabilities that cybercriminals are eager to exploit. Let’s explore five key ways legacy systems can significantly increase your cybersecurity risk:

1. Outdated security can’t keep up with modern threats.

Remember the massive Log4j vulnerability that shook the cybersecurity world in late 2021? Legacy systems, often running on unsupported operating systems or software versions, miss out on critical security patches like these. This exposes them to known vulnerabilities attackers can easily leverage to access sensitive data or disrupt operations.

2. Legacy dependencies on aging hardware and software.

Many legacy systems rely on outdated hardware and software for core functionalities. Not actively developed or supported, these components are often riddled with unaddressed security flaws. For a recent example highlighting the security risks posed by outdated software, the Adobe ColdFusion vulnerability CVE-2023-26360 case is a strong illustration. In 2023, threat actors actively exploited this flaw to breach systems, including two U.S. federal government agencies, targeting their outdated versions of ColdFusion. Hackers exploited this vulnerability to gain access, install malware, and perform reconnaissance activities on the compromised systems. However, prompt defensive measures thwarted lateral movement and data exfiltration.

3. Limited visibility into security posture.

Legacy systems often lack the built-in security features present in modern platforms. They may struggle to integrate with modern security tools like Security Information and Event Management (SIEM) systems, hindering the ability to have a comprehensive view of a company’s security posture. This lack of visibility makes detecting suspicious activity or potential breaches within the legacy system difficult.

4. Accidental exposure of internal applications.

As business needs evolve, internal applications running on legacy systems can unintentionally be exposed to the internet over time. This creates a direct path for attackers to target them. One example is the 2023 Microsoft Azure data leak, where sensitive internal data was accidentally exposed due to a misconfigured endpoint. This exposure allowed unauthorized users to access information meant to remain internal, underscoring how overlooked configurations in legacy systems and applications can lead to significant data security risks.

5. Slow integration of modern security solutions.

Legacy systems often require significant modifications or complete rewrites to incorporate modern security features like multi-factor authentication or data encryption. Migrating these applications to the cloud is often incremental, as each component needs modification to work securely in the new environment. Until these applications are fully adapted, they’re more vulnerable to attacks and may not benefit from the cloud provider’s built-in security features.

Modernization is the path to a stronger security posture.

Ultimately, a long-term plan for modernizing or replacing legacy systems is crucial for a robust cybersecurity posture. Synchrony’s Modernization Lifecycle Platform (MLP) supports this process by automating the migration and transformation process, enabling collaborative workflows, and offering clear, traceable insights into software modernization. Continuous Modernization (CM) complements DevOps practices like Continuous Delivery (CD) and Continuous Integration (CI) by allowing organizations to apply software updates consistently and incrementally. This method enables smooth upgrades across in-house applications, APIs, and other software components, regardless of underlying technologies, keeping security and functionality aligned with evolving needs.

Why modernize EGL applications?

Enterprise Generation Language (EGL) was a powerful tool in its time, but the technological landscape has evolved significantly. Modernizing EGL applications is crucial for businesses to remain competitive and agile.

Here are the primary reasons to modernize:

1. Improve user experience:

Outdated interfaces: EGL applications often have dated user interfaces that are not intuitive or mobile-friendly.
Enhanced user interaction: Modernization can create engaging, responsive interfaces that meet contemporary user expectations.

2. Increase efficiency and productivity:

Legacy systems bottlenecks: EGL applications might have performance limitations or scalability issues.
Automation: Modernizing can incorporate automation and AI to streamline processes and reduce manual effort.
Integration: New technologies enable seamless integration with other systems and data sources.

3. Reduce costs:

Maintenance overhead: Legacy EGL applications can be expensive to maintain due to limited skill sets and support.
Infrastructure costs: Modernization can reduce hardware and software costs by leveraging cloud-based solutions.

4. Enhance security:

Vulnerability risks: Older applications are often susceptible to security threats.
Compliance: Modernization can help meet industry regulations and data protection standards.

5. Unlock business opportunities:

Data-driven insights: Modernized applications can leverage big data and analytics for better decision-making.
Innovation: New technologies and platforms enable innovative products and services development.

6. Talent acquisition and retention:

Skill gap: Finding developers with EGL expertise can be challenging.
Attracting talent: Modernizing aligns the technology stack with current industry standards, making the company more attractive to skilled professionals.

7. Future-proofing the business:

Technological advancements: Staying up-to-date with technology is essential for long-term success.
Agility: Modern applications are more adaptable to changing business needs.

In essence, modernizing EGL applications is not just about updating the technology; it’s about transforming the business to be more efficient, competitive, and customer-centric.

We offer various solutions, including upgrades and transformations, to migrate your legacy EGL applications to a more modern architecture. Visit our EGL modernization page to learn more.

New experience report reveals details of modernizing six Smalltalk applications to Java

Company Saves Seven Years by Partnering with Synchrony Systems

Greenwich, CT (October 17, 2023) – Synchrony Systems, Inc., a technology pioneer for the management and execution of complex application modernizations, released an in-depth experience report on the modernization of six Smalltalk applications to Java. It describes the unique three-year collaboration between Synchrony and a German IT services provider for the financial sector.

“This project provided an opportunity to turn the modernization experience on its head,” said Synchrony Systems CEO Slavik Zorin. “We co-developed a true collaborative approach that allowed the company’s engineering team to retain control and have complete visibility into all phases of the modernization process while allowing the application development and modernization to run in parallel. Together, we shrunk an estimated 10-year rewrite of well over two million lines of code down to three years.”

“With Synchrony’s help, their advanced technology stack, and a strong team, we completed migrating all of our Smalltalk applications to the desired target Java architecture and were finally able to retire Smalltalk,” stated the company’s modernization project lead and veteran software developer. “We could not have done it without Synchrony’s technology, modernization expertise, and strong commitment to success.”

The Modernization Experience Report includes details such as:

company and project background
modernization initiative challenges, requirements, and vendor selection
Synchrony Smalltalk Migration Technology (SMT) and modernization platform overview
modernization readiness phase, including work breakdown, team collaboration, and project timeline
modernization implementation phase, including parallel track progress, halfway evaluation, functional testing, and code quality
final deliverable, conclusion, and takeaways
an appendix, including analysis of the codebase, pipelines, operations, deliveries, and more

This in-depth report is available for limited release to companies interested in understanding the details of modernizing large, legacy applications. Request your copy.

How to prepare for legacy application modernization

In-house applications, once associated with good fortune, have now become an albatross. These systems may still run business-critical processes or orchestrate data between commercial systems, but their underlying, aging technology has become a real liability. You know it’s only a matter of time before something fails, and it won’t be pretty.

You may be hearing a lot of bluster about the best way to go about modernizing legacy applications. “Refactor,” “re-platform,” “encapsulate and expose for microservices,” “lift and shift,” and “low-code rebuilds” are just a few of the buzz-phrases floating out there. At Synchrony systems, we also have our own view of how best to modernize. But the how is not always as straightforward as some try to make it seem. How to modernize depends on many factors that span well beyond source code or target technology.

So where do you begin? The following steps should not only help you prepare for legacy application modernization; they also should help you clarify the right modernization methodology to pursue.

Know what you have: document your current state

While this may sound like a no-brainer, you’d be surprised at how many companies don’t have a complete, up-to-date overview of their technology stack. Perhaps that’s because they’re busy putting out daily fires or launching new initiatives. Or maybe staff turnover put the critical, technical documentation on the back burner. Regardless of the reason(s), before starting any potential modernization initiatives, you must possess a full technical understanding of your IT portfolio and which parts of it are mission-critical to your business operations.

Three dimensions of the current state must be well understood: architecture, timeline, and capital.

Architecture: While it’s ok to not have all the answers, accurately describing what you know—and highlighting what you don’t—is important.

Do you have access to the source code of your in-house applications?
Do you understand your applications’ source platform dependency?
Do you understand your applications’ component architecture?
Do you understand your applications’ runtime architecture?

Timeline: Many in-house applications are built using licensed, 3rd-party software. Understanding the timing of the maintenance and support contracts is an important input to the modernization effort.

Capital: Capital includes the dollars used to support the in-house applications, as well as the resources and time spent maintaining them. You also need to understand what other IT projects your company is currently funding, the budget for the modernization initiatives, and when those funds will be available.

With this information, you can start to map out the priorities for your modernization.

Know where you want to be: document the future state

Sometimes the future state has a strategic mandate from the top—become cloud-first or consolidate technologies onto a single platform. Other times, the future state evolves more organically. Regardless of the path, you need a documented roadmap of the new vision for IT. This plan is really a risk-mitigation strategy for your legacy applications. It’s only a matter of time before the old versions start to fail, their security gets breached, a 3rd-party vendor stops supporting the software, or some other business-impacting event occurs.

Like the current state, your future state plan has the same three dimensions: architecture, timeline, and capital.

Architecture: Future state technology architecture needs to be aligned with the business need, and not just be technology for technology’s sake. The tech vision must map to the business vision and support the business value of investing in modernization. Along with technology, the future state should include recommendations about the people and process changes required to operate in this new architecture.

Timeline: Modernizations can be lengthy projects with many concurrently moving parts. A strong roadmap includes critical dates such as contract renewals, end of support, and/or end of life. It includes budget cycles for funding, and it maps critical hires such as short-term contractors, modernization specialists, and/or full-time developers/IT professionals. The roadmap also should include important business dates like acquisitions, major product launches, peak selling seasons, etc. All these factors can help shape your modernization priorities and urgency.

Capital: In addition to the investment allocation for the initiative, you also need to understand the capital outlay needed for resources—internal and external—required for success.

Determine the path forward

Now you can perform a gap analysis of the current and future states. The timeline and available capital will be key factors—the “how”—that inform your approach to modernization.

Another factor to consider is the relative effort of modernization. For example, rewriting an application from scratch is not only time-intensive from a greenfield development standpoint, but the effort to make it operational would include retraining users, rewriting documentation, re-tooling support, etc. Many hidden costs of rip-and-replace strategies that may be overlooked during the initial scoping will later become quite burdensome.

For very small, in-house applications with minimal business impact, simple migration tools may be all you need for the modernization. For very large, in-house applications, the strategy may be more complex and consist of several approaches, including:

Rip and Replace: replace with an off-the-shelf alternative
Lift and Shift: re-platform or re-host the entire legacy workload onto a virtual cloud environment
Rewrite: retire and invest in ground-up greenfield development
Re-architect: attempt to improve in place the underlying legacy application architecture into a more modern, service-based, web architecture.
Migrate: using automation, migrate “as-is” to a new target platform, preserving functionality and user experience

At this stage, talking with companies that specialize in modernizations is a wise idea. With the groundwork you’ve done, modernization experts should be able to give you a proposal for moving forward, a timeline, and a cost estimate for the modernization.

Start now

As Benjamin Franklin once said, “By failing to prepare, you are preparing to fail.” It’s never too early to begin the work necessary for a clear strategy to move away from your legacy applications.

At Synchrony Systems, we have over two decades of experience helping companies modernize their legacy, mission-critical applications in the most cost-effective and transparent way possible. Whether you are just starting to think about modernization or have an urgent need, we are happy to talk with you about your specific situation.

Smalltalk application modernization technology

Smalltalk is a dynamic programming language and a pioneer in object-oriented technology. Its versatility, simplicity, and elegance allowed people to rapidly build complex systems across a variety of industries and applications.

Although other programming languages surpassed Smalltalk in popularity for commercial application development, few captured its unique capabilities.

This makes Smalltalk applications difficult to replace without giving up design and functionality.

The trusted experts at Synchrony Systems have spent over two decades developing technology to address the unique challenges in modernizing Smalltalk applications. Our solution fast tracks Smalltalk modernizations to meet digital transformation demands while preserving the functionality and elegance of the original design. Our solution is designed to prevent operational disruptions — no code rewrites, no code freezes, no halts in development.

Previously, dynamically-typed systems were not good candidates for migrations.

Today, Synchrony’s Static Typing Engine makes these migrations possible. It’s the only proven solution in the market that turns dynamically-typed Smalltalk into statically-typed Smalltalk. It accurately identifies live code and isolates execution paths that are then rapidly migrated or deprecated. The analytical capabilities of our solution give you complete visibility into the Smalltalk interactions within your system. This allows you to extract functionality and migrate it to properly architected microservices.

The entire Smalltalk modernization process is managed through Synchrony’s Modernization Lifecycle Platform. MLP provides an automated, incremental, and agile modernization experience for all stakeholders–from analysis and planning to transformation and remediation to build and deployment to testing and production release. All without impacting the production version of your Smalltalk application or interrupting your day-to-day business operations.

With Synchrony, drastically reduce the cost and eliminate the risk and failure that comes from a rewrite with the most advanced Smalltalk modernization solution on the market.

Ready to launch your Smalltalk into the future? Contact Us.

What are legacy applications? Definition & guide

Our business is the modernization of legacy applications, and we talk about it a lot. Recently, Kathy Bazinet, an IBM Software Technical Sales leader, reached out to us on Twitter and asked:

“I would be really interested in your definition of “legacy applications”. Are you referring to monolithic Java or to COBOL or even something else?”

We thought this was a great question and wanted to share our definition with a broader audience.

How we define legacy applications

You can have a monolithic application written in a modern programming language or environment. Adjectives like “monolithic” or “fat-client” describes how the application is architected. You could argue whether or not a monolithic architecture makes an application legacy.

To us, an application becomes a legacy when what is under the application “layer” — be it a software library or framework, a programming language, or a database — goes out of style or worse, is no longer supported.

Today applications can experience such fate rather quickly. For example, Angular/JS is a modern-day SPA framework from Google that is quite popular. But that technology is now obsolete and has been replaced by another version of that framework renamed to Angular (dropping the JS part). While similar in name, applications are developed quite differently with it. So, a “modern-day” web application developed using Angular/JS is now considered a legacy application.

You can consider a programming language such as PHP to be a legacy web development language as well. Any web applications built with PHP are arguable legacy. Therefore, it’s not only monolithic mainframe or fat-client desktop applications that are legacy. Anytime a software environment or language is no longer supported by its vendor or loses its following, all applications built with it turn into legacy.

Tech debt, therefore, is literally the “drag” that antiquated software platform imparts on its host applications. To modernize these applications, you must first modernize their underlying software platform on top of which they were developed. Once an application is on the modern platform, you are ready to modernize its architecture.

Do you have a modernization question for our team? Shoot us a quick message and we’ll get back in touch with you.

Thanks again to Kathy for the question and the opportunity to share our point of view!

Why UX equivalency matters in modernizations

Mission-critical IT applications that are built in-house have been in development for hundreds of person-years, with many dozens of engineers and testers responsible for their years of maintenance, which would translate to hundreds of millions of dollars. More often than not, the documentation is scarce and inadequate to effectively support and especially to maintain these systems. Yet the users of the system are very proficient and efficient in implementing it. They have developed their own custom shortcuts and tricks for getting their jobs done.

Rewrites or wholesale replacements of the mission-critical application inevitably leave the company with an entirely different system. In addition to the cost, time, and effort needed to replace a legacy system, an IT organization also would be required to retrain the end-users on the new system and replace all the manuals and documentation. This costs the company not only money but precious time.

Retraining the workforce is a big disruption for a business. This is why many modernizations are delayed until the situation turns dire—when the infrastructure will no longer support the system or there isn’t anyone left to maintain it.

But it doesn’t have to be this way.

What is UX equivalency?

What we mean by user experience (UX) equivalency is that the modernized system would remain recognizable to the end-user and would be 100% equivalent from a usability perspective. With today’s technology, we can take a hosted/mainframe or desktop system and recreate the exact same look, feel, and behavior in a browser.

Similarly, a Windows-based MDI-type GUI application that uses drag and drop, tables, spreadsheets, graphics, modal/modeless dialogs, etc., also can be modernized to work in the browser as an HTML5 Single Page Application (SPA) with equivalent GUI functionality, richness, and presentation semantics. And we can do this without any special browser plug-ins or any desktop deployments. When the user types in a URL, the usability and functionality of their system will remain equivalent inside the browser, with all the benefits of being in a modern programming language and platform.

What are the benefits of UX equivalency?

A pure technologist may argue against having the modernized application look and feel like the dated application, but the business benefits are far too great to ignore. These include:

No end-user retraining for internal, external, or even paying customers
No need to update support, knowledge bases, training manuals, or any other documentation
No need for a massive change management overhaul
No degradation in performance; preserves all built-in performance efficiencies developed by engineers over the years
No productivity loss; preserves all the known productivity shortcuts already developed by end-users
No production release delays; following user acceptance (UAT), a modernized application is ready to go live

Only a modernization that guarantees UX equivalency can ensure no operational disruptions to the business. UX equivalency really focuses on eliminating the hidden costs associated with modernizations.

Hidden costs savings of UX equivalency

These hidden costs of modernizations due to a new UX can be quite staggering, especially if it necessitates retraining a sizable workforce or one that is dispersed worldwide. To illustrate the impact, here’s an example of an enterprise insurance company.

This insurance company had a propriety system that handled all their rating and quoting. Customers would call the company to obtain quotes on their automobile, homeowners, or other insurance, and the agents would enter this information into the system to supply the quotes. In addition, the company also relied on a distribution channel of third-party agents to help drive new business. These third-party agents typically were employed by small insurance companies that also used the system to provide quotes to prospective customers.

In the case of a new UX, this company would need to retrain all of its 10,000 employees on the new system, as well as their external workforce, a network of 20,000 independent insurance agents. Once the company began adding these additional costs, the modernization would become both expensive and disruptive. While this is feasible, the opportunity costs are quite high and the impact on the end-user experience could be overwhelming.

A modernization approach that ensures 100% UX equivalency would prevent the pitfalls described above and allow the entire workforce of 30,000 agents to continue their day-to-day operations with no interruption and little to no impact on the overall business.

UX equivalency helps the developers, too

UX equivalency also is important for the developers who update, modify, and support the modernized application. The learning curve of a modernization application would be limited to only the adoption of a new programming language. Structurally, the source code would remain the same. Any test automation scenarios built over the years would remain unchanged, and the engineers and testers would be able to use them on the target platform. Therefore, developers would be able to smoothly transition to the new platform and apply their domain expertise to further enhance and maintain the system, with minimal impact. Once the modernized application goes live, both the end-users and the developers would remain 100% productive in running and maintaining the modernized system.

Synchrony Systems guarantees 100% UX equivalency in modernizations

Synchrony understands that modernizing a large and complex legacy application can be a major undertaking, fraught with high risk and expense. It doesn’t have to be this way. Our approach and methodology, backed by the power of MLP, accelerate the modernization time-to-value and guarantees functional and UX equivalency. We balance the overall speed, cost, quality, and risk while creating a unified experience, in order to address the inherent complexity of a modernization process in a frictionless and predictable way.

Contact us to learn more about how we can help you maintain 100% UX equivalency on your modernization initiative. Your users will thank you!