Insights / Software modernization

Rebuilding MERP and PREP while people still depended on them

Rebuilding MERP and PREP while people still depended on them

We rebuilt MERP and PREP across web applications, mobile apps and backend services while organizations continued to depend on them for emergency information. That shaped the whole engagement: the information people needed, the way they accessed it and the transition to the new product.

The people using the product could not wait for the rewrite

MERP is an emergency preparedness product for Safeguard Risk Solutions, serving education, businesses and other organizations. PREP serves hospitals and healthcare organizations through HAPevolve.

Both products help staff reach emergency response plans, contacts and procedures. A person using that information may be under pressure, working from a phone or switching between devices. Access and fast navigation have a practical role in the task they are trying to complete.

Our modernization work began with stakeholder interviews and a review of the code, database and infrastructure. We turned those findings into functional specifications and delivery priorities.

The product crossed several technical boundaries

The engagement covered the web frontend, mobile applications, backend and DevOps, together with data migration and cutover. QA and a dedicated test environment supported delivery.

The dependencies between those parts mattered to the user. A plan may be present in the database but still be difficult to reach through the application. A sign-in flow may work while a permission prevents someone from opening the information relevant to their organization.

Parts of the MERP/PREP modernization that had to work together
AreaWhat the delivery needed to cover
Web and mobile accessUsable navigation to emergency plans, contacts and procedures across devices.
Identity and permissionsOrganization access and the ways people reached their information.
AccessibilityKeyboard navigation, screen-reader behavior, focus and contrast.
Migration and releaseThe data, applications, infrastructure and cutover needed to introduce the rebuilt product.

SSO infrastructure and configuration guidance addressed identity integrations including Microsoft Azure and Okta. Mobile offline access also helps keep information within reach when connectivity is disrupted.

Availability and accessibility belong in the delivery plan

Continuous availability, fast access and usability across devices were core requirements during the rebuild. The migration needed to preserve emergency plans, document access and organization permissions.

Migration review also covered the ordering and colour assignments of plan and task tabs. An existing arrangement can help staff recognise where to go. Moving the underlying information needs to account for that familiar organization too.

The practical lesson for another modernization project is to agree the user journeys that must keep working through the transition. Identify which information each journey requires, who should have access and which devices people use to reach it.

Review those journeys with the people responsible for the product. Use the findings to connect application work, data checks and release planning. Accessibility checks should be part of that review so that successful access means being able to complete the task.

The changeover was part of the work

Our delivery team reports a cutover to the rebuilt platform without service interruption or crashes, with many users continuing their work without noticing the rewrite.

That outcome matters because the engagement covered a complete rewrite across the frontend, mobile applications and backend. The team had to deliver the transition alongside the new software.

The team also reports 90% lower AWS costs after modernization. Operating costs were one outcome of the engagement, alongside continuity, usability and a foundation for ongoing improvements.

Keep learning from the product after launch

The engagement continued through product care, connecting customer feedback with further changes. Perspective Unity reports faster improvements within the ongoing product-care budget and fewer recurring customer escalations.

For another software owner, a useful starting conversation covers the product people use today, the work the next version needs to support and the constraints on changing over. Existing plans, access arrangements and dependencies give that discussion substance.

Explore the MERP/PREP modernization case study for the full delivery scope. If you are planning a similar transition, see how we approach legacy application modernization.

Perspective Unity