Preparing Your P21 Environment for SaaS in Microsoft Azure

As more Prophet 21 customers begin planning their transition from on-premises or privately hosted environments to P21 SaaS in Microsoft Azure, one of the most important early steps is understanding what exists around the core ERP system.

​

For organizations with relatively standard P21 environments, the transition may be fairly straightforward.

​

For highly customized P21 environments, however, the work surrounding the migration can be much more significant.

​

Custom business rules, integrations, reports, SQL processes, forms, scheduled jobs, external applications, and other supporting technology should be identified and evaluated well before the planned SaaS cutover.

 

The goal isn't simply to ask: “What do we have to move?”

​

It's also an opportunity to determine:

• Which customizations are business-critical and need to be carried forward

• Which customizations may be outdated or no longer necessary

• Which can migrate with little or no change

• Which need to be tested or reconfigured

• Which need to be updated, redesigned, or redeveloped for P21 SaaS

• Which integrations may require changes to their current data-access methods or architecture

• What development, testing, and implementation work should be incorporated into the overall migration timeline

 

For highly customized environments, beginning this discovery process early can make a significant difference.

 

Start With a P21 Customization & Integration Inventory

Before deciding what needs to change, first identify what you have.

​

Create an inventory of the components currently supporting your P21 environment. For each item, document its business purpose, owner, criticality, current technology or data-access method, and whether it interacts with systems or resources outside of P21.

 

Your inventory may include:

• Business Rules and Visual Rules

• DLL extensions

• DynaChange customizations

• Crystal Forms

• Report Studio reports

• SSRS and other custom reporting

• Custom DataStream objects

• Legacy InfoMaker portals

• SQL Agent jobs and alerts

• SQL functions and stored procedures

• Third-party integrations and middleware

• Custom web applications

• External applications and supporting tools

 

Epicor may also provide a P21 Cloud Migration Summary containing many of these items, which can provide a useful starting point for your technical review.

​

Once the inventory exists, your team can begin determining what should be carried forward, what needs additional testing or configuration, what may require redevelopment, and what may no longer be necessary.

​

Keep it. Retire it. Test it. Reconfigure it. Or rebuild it. 

 

P21 SaaS Customization, Integration & Technical Readiness Guide

We've put together a more detailed technical readiness guide to help P21 customers work through their existing environment and identify areas that may require additional evaluation during a SaaS migration.

​

The guide includes considerations for:

• Business Rules and Visual Rules

• DLL extensions and DynaChanges

• Crystal Forms and Report Studio

• SSRS and other custom reporting

• DataStream objects

• Legacy InfoMaker portals

• SQL Agent jobs and alerts

• SQL functions and stored procedures

• Third-party integrations

• Middleware

• Custom web applications

• External tools and applications

 

It also provides practical starting points for gathering the information needed to evaluate each area.

→ View the P21 SaaS Customization, Integration & Technical Readiness Guide 

 

What Changes When P21 Moves to SaaS?

Moving P21 to SaaS isn't simply a change in where the ERP is hosted.

The underlying operating environment, database access, integration methods, reporting architecture, and ability to interact with local or external resources may also change.

​

That doesn't necessarily mean every customization or integration needs to be rebuilt.

​

Some components may migrate with little or no change. Others may require configuration or testing. Some may need a different technical approach or redevelopment to operate successfully within the P21 SaaS environment.

​

The important part is identifying those differences before they become late-stage migration problems. 

 

Business Rules & Visual Rules

Business Rules and Visual Rules should be included in your migration inventory and tested as part of your SaaS preparation.

Rules that already operate successfully within the P21 Web UI may require little or no modification.

​

Additional attention should be given to rules that interact with resources outside of P21, including local file paths, external databases, SharePoint folders, or other systems and applications.

​

A practical approach is to use the P21 SaaS PLAY environment to validate business-critical rules and identify those that are not behaving as expected.

​

Once problem rules have been identified, their requirements and source code can be reviewed to determine what changes may be necessary. 

 

Reporting

Reporting requirements should also be evaluated early.

Standard P21 reporting components may migrate as part of the overall P21 migration, but custom SQL-based reporting may require additional planning.

​

For example, SSRS reports that will remain in use may require a local or privately hosted SQL/reporting environment and approved connectivity to the P21 SaaS Replicated Read-Only Database.

​

Report data sources may need to be reconfigured and then validated for performance and expected output.

​

This is also a good opportunity to evaluate whether older reports are still being used and whether some reporting requirements could be addressed through newer P21 reporting capabilities. 

 

SQL Jobs, Alerts & Processes

SQL Agent jobs and other scheduled SQL processes deserve particular attention during migration planning.

​

Jobs that depend on local resources, local file paths, outside databases, or other systems may need an alternative approach in the SaaS environment.

​

An existing alert, for example, may be better implemented as a scheduled report. A job that writes output to a local server path may require a different destination or architecture.

​

The first step is simply to identify the SQL jobs currently supporting your environment and document what each one is intended to accomplish.

​

From there, each process can be evaluated to determine the most appropriate approach in P21 SaaS. 

 

Integrations, Custom Applications & External Tools

Every third-party integration, middleware process, external tool, and custom web application should be evaluated to determine whether its current integration method is compatible with P21 SaaS.

​

For each integration, document:

• Current integration method

• REST API, SFTP/flat file, data upload, direct SQL, or another process

• P21 objects and data being exchanged

• Direction of the data flow

• Frequency of the integration

• Real-time requirements

• Dependencies

• Local or privately hosted infrastructure currently involved

 

With that information, a developer can determine what can remain unchanged, what requires configuration, and what degree of redevelopment may be needed.

​

This is particularly important for organizations that have accumulated integrations and supporting applications over many years. 

 

Use the Migration as an Opportunity to Clean House

Not every customization needs to survive the move.

P21 environments often evolve over many years. Business requirements change. Employees change. Processes change. New functionality becomes available.

​

Yet old reports, rules, integrations, jobs, and applications can remain long after the original requirement has disappeared.

​

A SaaS migration creates a natural opportunity to ask: Do we still need this?

​

Before spending time and money recreating an old customization, determine whether the underlying business requirement still exists.

In some cases, the best migration strategy isn't redevelopment.  It's retirement.

 

Don't Wait Until Cutover to Discover the Custom Work

For organizations with highly customized P21 environments, the biggest risk may not be the core ERP migration itself.

​

It may be discovering too late that an important integration, SQL process, report, business rule, or external application requires additional work.

​

Early discovery gives your organization time to:

• Understand the scope of required changes

• Establish development priorities

• Coordinate responsibilities between your team, Epicor, MindHARBOR, and other vendors

• Redevelop or reconfigure components where necessary

• Test within the P21 SaaS environment

• Complete user acceptance testing

• Resolve issues before the production cutover

 

The more customized your environment, the more important that runway becomes.

​

How Much Help Do You Need?

There isn't one right level of assistance for every P21 SaaS migration.

​

MindHARBOR can participate as much or as little as is valuable to your team.

​

For some customers, that means providing technical guidance and participating in meetings with their internal team and Epicor as an additional technical resource.

​

For others, it means a more comprehensive technical discovery and assessment followed by redevelopment, modification, testing, and deployment of the customizations and integrations that need to change for the P21 SaaS Azure environment.

 

MindHARBOR can help with:

• Reviewing P21 customization and SQL inventories

• Participating in migration meetings with your team and Epicor

• Evaluating business rules, SQL processes, reports, integrations, and external applications

• Identifying likely SaaS compatibility gaps and recommended approaches

• Reconfiguring or redeveloping custom solutions

• Assisting with Epicor cases and technical coordination

• PLAY environment testing

• User acceptance testing issue resolution

• Deployment

• Post-cutover support

 

Highly Customized P21 Environment? Start Early.

If your organization has a highly customized P21 environment, allow adequate time well before your planned migration date.

​

Early discovery provides an opportunity to understand and document the extent of required changes, establish development priorities, and create a realistic timeline for redevelopment, testing, user acceptance, and deployment before the final P21 SaaS cutover.

​

The earlier you understand what needs to change, the fewer surprises you're likely to encounter as the go-live date approaches.

 

Free P21 SaaS Migration Checklist

Not sure where to begin?

 

Use our P21 SaaS Migration Checklist as a starting point for identifying the customizations, integrations, reports, SQL processes, and supporting applications that should be evaluated as part of your migration planning.

→ Download the Free P21 SaaS Migration Checklist

 

Need Help Preparing for P21 SaaS?

Whether you need a little technical guidance, assistance working alongside Epicor, a review of your existing customizations and integrations, or hands-on redevelopment and migration support, MindHARBOR is happy to help.

​

We work alongside your internal team, Epicor, and your other technology partners to help identify and address the technical pieces surrounding your P21 SaaS migration.

​

Custom Solutions. Not Products.