Security or compliance requirements 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.

Brownfield software development guide

Brownfield refers to physical land requiring clean-up, upgrades, or development before leveraging the property for new purposes. Brownfield software development describes maintaining, upgrading, migrating, interacting with, or leveraging data from legacy applications.

Most of the world’s developers work on and within brownfield applications and environments. While greenfield software development gets the industry buzz, it’s the brownfield technologies with mass adoption and most usage that run companies.

Challenges in brownfield software development

Brownfield software development is not easy. The developers must keep brownfield applications up-to-date, transform critical legacy business logic to modern technologies, and architect interoperability between brownfield and greenfield applications and environments. Some key challenges with brownfield software to note are:

Not having a thorough understanding of the legacy applications and their dependencies with other legacy platforms
Staffing technical expertise to continue the development and maintenance of legacy applications
Developing a strategic modernization roadmap and rapidly executing it while reducing technical risks and business disruptions
Determining which parts of legacy applications are business-critical and must be preserved, maintained, migrated, replaced, or retired
Managing upgrades, migrations, integrations, and modernization of legacy applications in a consistent, uniform, and repeatable manner while continuing active maintenance (no halts in development).

The inability to adequately address these issues and challenges will have a costly impact on the current and future business.

Adopt continuous modernization to help solve brownfield application development challenges

Instead of the obsolete top-down / waterfall approaches in greenfield applications, development teams have adapted leading DevOps principles such as continuous integration (CI), continuous testing, continuous monitoring, continuous security, and continuous delivery (CD) to take a more agile and iterative approach. Incorporating the continuous modernization (CM) principle to brownfield applications should be a natural extension of DevOps to enhance and fully complete the cycle of software development, maintenance, and evolution.

The principle of continuous modernization is to avoid the need for large, time-consuming, costly, and risky undertaking of major modernization initiatives in the brownfield software space. Executing a continuous modernization strategy requires different processes and automation tools to manage software migrations, modernizations, and upgrades while coexisting with ongoing greenfield and brownfield development projects.

One such tool is MLP, a SaaS platform that brings a uniform upgrade process, a collaborative work environment, and transparent and traceable workflows to continuous modernization. It snaps into your existing CI/CD environments and procedures to give you the ability to apply new software updates systematically and incrementally to your in-house applications, APIs, or any other software components.

Benefits of continuous modernization for brownfield software

Leveraging automated modernization workflow management tools and platforms like MLP for brownfield software upgrades, maintenance, integrations, and modernizations will benefit the business in many ways. Some of the benefits offered by continuous modernization for brownfield applications are outlined below:

Accelerate adoption of native, cloud-first, and mobile application architecture
Fast-track digital transformation projects to accelerate delivery of business value
Reduce security risks associated with legacy applications
Keep currency with a rapidly changing technology landscape
Improve performance of brownfield applications
Continuously eliminate creeping technical debt
Prevent massive modernization initiatives in the future

In short, continuous modernization makes it easier to support brownfield application development by providing a systematic, uniform, and accelerated approach to executing modernization roadmaps without disrupting the day-to-day business operations.

Learn more about continuous modernization.

IT modernization insights for government CIOs

A few of our team members attended the Beyond the Beltway 2022 – Virtual Event hosted by the Center for Digital Government. It was an incredible opportunity to hear directly from state and local government CIOs and CSOs. They discussed the initiatives they are working on, the tech trends important to their region, and the best ways the private sector can be a true partner in finding solutions to their problems.

One thing was certainly evident, government CIOs and CSOs have their work cut out for them. They have to balance federal directives with constituent service expectations within the constraints and protocols of the local governing body. The featured speakers from government organizations across the country were generous with their insights, and the sessions were expertly moderated by the staff at the Center for Digital Government. Here are a few things we learned about technology modernization at the state and local levels of government.

1. Strategic plans inform technology modernization considerations

Although the featured CIOs spoke to the specific needs of their region, they all stressed that their strategic plan, which is available to the public, guides all modernization considerations. Their projects reflect these overarching government directives heard throughout the event:

Keep our systems secure (cybersecurity)
Protect the privacy of our people (PII data)
Meet constituent expectations (digital engagement)
Support remote and hybrid workforces (secure cloud-based systems)
Prove compliance (tracking and reporting)

Any modernization project will advance progress towards the strategic plans and support the overarching directives.

2. CIOs use existing technologies, processes, people, and relationships wherever possible

The featured CIOs spoke passionately about being good stewards of taxpayer dollars. They always first evaluate and leverage existing systems and expertise wherever possible. Then, they review internal processes and skills and engage with partners they know and trust.

If a technology modernization initiative is needed, government CIOs reach out to each other looking for similar, successful projects. They want the highest probability of success with the least risk possible – and don’t want to re-invent the wheel.

3. Funding for technology modernization is only part of the solution

Yes, having money allocated for technology modernization is great. But the CIOs stressed that the funding is only a piece of the overall initiative. The more significant challenges lie in the execution of getting the project completed.

Government CIOs are looking for holistic proposals beyond the specific technology solution. The proposals must also include:

External experts assigned to the project
Internal IT resources required to support the project
Best practice frameworks and guides
Relevant case studies
Knowledge transfer plans
Long-term support considerations (maintenance fees, upgrades, training, etc.)

Comprehensive plans help give the CIOs confidence that the modernization project is successful and sustainable.

One final point stressed by several of the speakers – it’s challenging to retain internal IT talent within the government. It’s a very competitive job landscape, with many choosing employment in the private sector. Therefore, CIOs tend to give favor to external suppliers who will help upskill and reskill government employees to support the modern technology and processes

4. Technology suppliers need to do their homework

The public availability of contact information for government IT staff makes reaching out to the CIOs incredibly easy. While our speakers welcome the outreach, they are often disappointed that technology suppliers haven’t researched what matters for that specific CIO office. The cold outreaches are broad, generalized, and focused on selling to the CIO.

Government CIOs want the outreach, but they want to understand the pitched technology fits within the context of their strategic plan and the ecosystem of providers they already use. This information is publicly available, so they want suppliers to do their homework and frame the solution in the following ways:

Plan – what specific initiatives or directives does the technology modernization support?
People – who are the people involved, and how will others and the community benefit?
Process – what process improvements does the technology modernization support?
Technology – what are examples of it working for similar organizations solving like challenges?
Policy Implications – what are the policies considerations surrounding the technology?
Performance – how do we measure and share positive outcomes resulting from technology modernization?

The final thought one CIO offered to technology vendors was, “bring me leading edge, not bleeding edge, tech.” The agreement was while cutting-edge technology may be interesting, it doesn’t have a place in government until sufficiently proven.

5. Public CIOs want true partnerships with private sector technology providers

State and Local CIOs are operating to plans that extend years into the future. They also are tying every technology investment to the needs of their community, such as democratizing broadband access and keeping their citizens safe from cybercriminals. These challenges can’t be solved with a single technology or even within a single administration. And the balancing forces within the government mean technology modernization progress is slow compared to the private sector.

Therefore, government CIOs want partners with them for the long haul. They want partners committed to being a part of the solution beyond the technology they may provide. Partners who can bring ideas, best practices, and other partners and who take the time to build a personal and trusted relationship give the most value. Those are the partners who work on the government project.

Synchrony Systems’ work in state and local government

We have been fortunate to serve several state and local government organizations such as Bay Area Rapid Transportation (BART), City of Atlanta Fire Department, Oregon State Judicial Department, and New York City Police Department. Through our trusted partnerships, we helped migrate and modernize their legacy applications to modern, cloud-based, and mobile-friendly applications and user interfaces.

Our automated migration and modernization technology allows our partners like IBM, Astadia, and TSRI to leverage our platform and expertise on government modernization initiatives efficiently and effectively.

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.

5 ways your legacy systems may add to cybersecurity risks

Not all technical debt is created equal. Many legacy business systems—whether architected in-house or purchased from software vendors—contain inherent security vulnerabilities that may be growing worse over time. In a recent Accenture study of government agencies, 85% of IT leaders believe not updating legacy technology will threaten their agency’s future. The Workplace Agility report from Capita and Citrix found more than half of CIOs surveyed think legacy applications are delaying digital transformation.

Here are five security vulnerabilities associated with legacy business systems:

1. Outdated security functionality doesn’t adapt to evolving threat landscape

Today’s hackers enjoy a target rich environment—in 2018, there were more than 15,000 known Common Vulnerabilities and Exposures (CVEs). When legacy systems were developed, these applications may have been on top of then-current cybersecurity practices. But with the passage of even a short time, the threat landscape evolves while many legacy systems get left behind.

Legacy systems may be incompatible with security features surrounding access, such as multi-factor authentication, single-sign on and role-based access, or lack sufficient audit trails or encryption methods. Whatever the reason, these systems are unable to accommodate today’s security best practices.

When security flaws are discovered in legacy software, they are widely published on security blogs and in industry journals. While it is important to update security professionals on vulnerabilities, hackers are also receiving a free education. In the case of legacy systems, cyber criminals have had years to perfect tools for exploiting well-known vulnerabilities.

2. Older hardware, software or databases create legacy dependencies

Sometimes it isn’t just that a legacy application lacks security features, but rather that the ability to continue using that legacy application is contingent upon a variety of legacy dependencies that introduce additional security vulnerabilities. These legacy dependencies can include hardware (such as old mainframe computers), database structures, operating systems, or other legacy software.

A classic example of legacy dependencies can be found within many enterprise ERP systems. Suppose you added a third-party reporting tool or created a customized barcode scanning application five years ago that integrated with an older version of your ERP. You should have upgraded your ERP system twice by now in order to benefit from security enhancements, but you have put it off because moving to the latest version of the environment would break the integrations between your custom apps or third-party solutions.

Over decades many organizations built a web of proprietary, interconnected, mission-critical business systems that still feed into legacy databases. A recent strategic technology plan for Grand Traverse County, Michigan gives an all too familiar description:

“The AS400 based applications that are running on the IBM Platform are in-house programmed over decades. This results in many application revisions by multiple programmers with little or no oversight into best practices for security and usability. This lack of oversight creates what is referred to as spaghetti code, or code that is difficult to untangle and secure.”

Grand Traverse County had built 57 custom applications on its outdated IBM mainframe environment, and the IT department requested over $6 million just to migrate to modern platforms and applications—about 1/10th of the county’s entire annual budget. Modernizing and securing spaghetti code can be complicated, causing many businesses to delay until after a security incident occurs.

Legacy dependencies can also create a drag on business that extends far beyond the IT department. Here are two ways they slow down or prevent the achievement of critical enterprise objectives:

In-house systems can hold back the development of a better customer experience. Are you unable to provide customers with self-service? Do you lack the ability to launch subscription products because a legacy billing system cannot provision and invoice for them correctly?
Legacy dependencies can stall a strategic move to the cloud and digital transformation. A recent survey conducted by market research firm Vanson Bourne found that 85% of enterprise digital transformation architects said legacy databases limit their ability to transform. During transformation projects, 60% of architects observed that managing legacy system involvement took too much of the IT team’s time.

3. Legacy systems lack full-stack security visibility

Legacy systems with spaghetti code also tend to leave discarded bits of code and tools hanging around—quite possibly in your production environment. Small apps may still be used by a few employees, but may not show up in IT inventories, even though they contain old open source code. Because these tools aren’t under active development anymore, there should be a plan to sunset them or modernize them, but if they slip off the IT radar, security lapses may ensue.

Java development magazine Jax cautions IT security professionals to

“Remember, any application – no matter how big, small, old, or new – is fair game for cybercriminals so businesses can shrink their threat surface by removing any potential footholds into their infrastructure. IT and security teams need to implement a plan and process for regularly reviewing their technology stack and sunsetting applications that no longer serve a business function.”

When business systems run on a modern platform, the IT department can utilize full-stack security solution suites to gain better visibility into enterprise-wide security.

4. Internal applications more likely to become externally exposed over time

Even businesses with good security procedures and the best of intentions about solving technical debt incur increased vulnerability over time with legacy systems. That’s because as years (or decades) pass, mergers, acquisitions and corporate restructuring may leave orphaned hardware and software that no one “owns” anymore. With nobody using these assets and no decommissioning plan in place for them, the legacy hardware or software bumbles along in the background, until one day an IT change inadvertently results in its exposure to the external world. An unguarded, unintended door open without anyone keeping an eye out for intrusions.

An example of this occurred when FedEx acquired a company called Bongo. Bongo’s legacy storage server went unnoticed as its IT assets were incorporated into FedEx’s environment. The result was an Amazon S3 server left unsecured online, sitting on FedEx’s network.

5. Legacy platforms lack the ability to implement additional layers of security quickly

Many security packages weren’t designed for legacy mainframe environments and operating systems. And the legacy applications themselves often lack the kind of real-time security monitoring needed to pin down and resolve security intrusions. Legacy systems might monitor performance, for example, but lack the details and contextual information that create the true visibility needed by security professionals. Audit trails and log functionality might be missing altogether or could be in a proprietary format that proves difficult to access and analyze.

The lack of adequate monitoring and logging can get enterprise businesses into trouble quickly if legacy applications are connected to both the internet and an internal corporate network. Once a legacy application has been exploited without triggering any alerts or logs, cybercriminals have free rein to run through the internal network cracking into other systems—potentially undetected—while the IT team lacks visibility into where the original intrusion occurred. By contrast, when you’re operating applications that are part of a modern cloud or hybrid tech stack, you can quickly and easily add plug-and-play security and network monitoring solutions that are interoperable with your platform.

Conclusion

The solution to legacy security vulnerabilities is tech stack modernization, followed by Continuous Modernization to keep future technical debt from accruing new security risks. Gain greater visibility into technical debt that might cause security concerns by creating an application catalog that notes legacy dependencies and assigns a measurement of risk. Then create a decommissioning plan to eliminate technical debt from the riskiest legacy systems first.

Synchrony’s Modernization Lifecycle Platform (MLP) brings an automated upgrade process, a collaborative work environment, and transparent and traceable perspectives to software upgrades. Continuous Modernization, or CM, is a complementary approach to the DevOps practices of Continuous Delivery (CD) and Continuous Integration (CI). CM gives enterprises the ability to systematically and incrementally apply new software updates to in-house applications, APIs, or any other software components, regardless of the underlying technology being upgraded.

Learn More

Yes, I’d like to learn more about Synchrony Systems Modernization and Continuous Modernization technology:

Government IT modernization RFP guide

As businesses and consumers rapidly advance in their use of cloud, mobile, and web 2.0 technologies, governments, and sectors such as energy are navigating their own IT modernization initiatives. They have a precarious balancing act of embracing digital strategies and mobile initiatives to serve the people while safeguarding sensitive information and using technology in smart, secure, and affordable ways.

Maintaining legacy systems is expensive. Over the last decade, the U.S. federal government spent roughly 75-80% of its IT budget on the operation and maintenance of its outdated legacy systems. Recently the U.S. Office of Management and Budget (OMB) has codified IT modernization as a key objective and is working closely with participating agencies to establish funds that can help replace legacy IT systems and produce modern IT equipment and services.

The U.S. federal government is not alone. U.S. state and local governments and governments around the globe are also striving to serve their constituents with modern technology while reducing the amount they spend on legacy systems. Their efforts to move to a digital, mobile-first engagement model often are held back under the weight of legacy systems—and, in many cases, smaller budgets.

Slavik Zorin, CEO of Synchrony Systems, has been in the software modernization field for over 20 years. He has worked closely with trusted government partners such as IBM and the “Big Four” firms helping government organizations transform their legacy applications, thereby reducing costs while gaining the benefits of modern architecture. He offers these tips when developing an RFI or RFP for your modernization initiative:

1. Look for options other than rip-and-replace proposals

In today’s age of digital transformations, something even more disruptive to the organization than the upkeep of its monolithic legacy systems is a monolithic, big-bang approach to modernizing these systems. Many of the default, go-to large System Integrators that respond to RFPs are continuing to offer antiquated, wholesale rip-and-replace solutions. At the outset, the time, resource, and dollar estimate of these approaches appears reasonable. However, the eventual cost is significantly higher than anticipated because of change requests arising from the continuously shifting requirements of an evolving legacy system during the modernization project. These change requests introduce a high risk to the modernization project and compound the cost and time to complete it. RFP reviewers need to be mindful of a proposal that offers a low initial price but has a contract designed for unlimited change request triggers.

In contrast, a new approach to modernization driven by 100% automation, provided by companies such as Synchrony Systems, changes the status quo. They offer a highly transparent, efficient, and predictable modernization solution at a fraction of both the price and the risk of the traditional rip-and-replace solutions. Not only does this new approach fit within the shrinking budgets of the public sector, but the process requires little to no internal IT involvement and no end-user retraining once the modernization project is complete.

2. Ask how vendors will preserve the functional equivalence

Your government IT professionals have spent years building systems specialized for your agency, department, or office. The final application was probably developed organically, adding functionality as needed and modified as the needs of the organization changed. Your IT “subject-matter experts” certainly know your systems inside and out, and those systems contain critical functionality to support your agency’s operations.

The challenge with legacy applications is not the functionality but the aging technology that the functionality is built upon. What necessitates the modernization are your maintenance costs, skills shortage, technical requirements imposed by the regulatory compliance changes, and overall inability to provide modern digital experiences to your constituents. The move to modern technology is no longer the debate. The question is whether the modernized system will be one that your IT department can recognize and continue to maintain as efficiently and effectively as it has been to date.

By looking for modernization solutions that focus on the preservation of the original investment into legacy applications, your organization will end up with modernized systems that have equivalent functionality and a recognizable user experience. Therefore, the transition plan to take ownership of the application in a new platform will be more immediate, operationally frictionless, and will have significant cost savings.

3. Understand the potential impact on the user experience

As mentioned before, rewrites or wholesale replacements of mission-critical applications inevitably leave the organization with an entirely different system. In addition to the cost, time, and effort of the traditional rip-and-replace modernization, your IT department would also be required to re-train all the end-users on the new system and update all internal processes and documentation. This hidden cost, which is often quite high, gets overlooked.

User experience (UX) equivalency means that the modernized system would remain recognizable to the end-user and would be 100% equivalent from a usability perspective. One modernization that Synchrony Systems performed was a mainframe application for the New York Police Department. Due to a tight budget, NYPD wanted to avoid any additional retraining that would typically follow a modernization project. Synchrony Systems offered a solution that would mimic exactly the look and feel of the 3270 green screens, but in the modern, native, browser-based technology. The modernized application was delivered within the promised timeframe and budget, without any change requests and, as promised, without any end-user retraining.

Some may argue against having the modernized application look and feel like the dated application, but the benefits are far too great to ignore, especially for the government. These benefits include no end-user retraining for internal or external users; no need to update support, knowledge bases, training manuals, or any other documentation; and no productivity loss because UX equivalency preserves all the known productivity shortcuts already developed by end-users. Only a modernization that guarantees UX equivalency can ensure no disruptions to the government’s operations.

4. Ask vendors how to avoid code freezes

Mission-critical legacy applications are typically in use every day (and sometimes 24/7). More often than not, these systems require frequent code changes to address the numerous changes in regulatory compliance and government operations.

Vendors that offer traditional manual rewrite modernization approaches are forced to impose “code freezes,” i.e., periods of time where no changes can be made to the application. Such is the nature of a wholesale rewrite; for the rewrite to have any chance to complete, the system must remain unchanged while it is in progress. For many organizations, this is simply prohibitive, hence the reason legacy applications remain on aging technology.

The ability to maintain and update the legacy application while it’s being modernized to a new technology entirely changes the dynamics of modernization projects. At Synchrony Systems, we are able to support the coexistence of modernization activities with ongoing development activities without any code freezes. Powered by our Modernization Lifecycle Platform, ongoing new releases of the legacy application are continuously synchronized by replaying all the recorded automation that has taken place up to that point. For companies like SoCalGas, with a proprietary system that had daily pricing changes, the elimination of code freezes was essential.

In reviewing the bids from your RFP, be sure to fully understand if code freezes are a part of the modernization process and how it may impact your organization.

In summary

The move to digital is an opportunity for the government itself to become more agile in its operations and service to its constituents. And, more than any other organization, the government must be completely transparent and ensure continued fiscal responsibility to spend taxpayers’ dollars wisely.

Using these few tips can put your organization on the right path for digital transformation.

The antiquated rip-and-replace and manual rewrite practices of traditional System Integrators are opaque, very expensive, and risky. Synchrony Systems offers a modernization process and platform that is fully transparent and predictable, rooted in technology and automation, and enables us to provide reliable and unchanging fixed prices that do not rely on hidden change-request practices that have been the status quo in this industry. If your organization or agency has this need and is looking for a guaranteed success that is fast, cost-effective, and risk-averse, send us an email or give us a call at (203) 355-3636.