Migrating Existing Flows into Infor CloudSuite

A large amount of our customers have been on Lawson for many years, which is another big factor in these pre-planning engagements and projects in general. This familiarity means they've developed very sophisticated flows, integrations, and extensions, so they're concerned about how those are going to migrate forward into CloudSuite. Today we’re going to explain what that effort and future state might look for a client in this situation.

This part is actually a big component in the effort required to complete a CloudSuite implementation. The move from an on-premise SQL database and global application-based system to a cloud software as a service delivery method means that essentially all of your interfaces will change. This alteration will impact not only how they're written but even how the software responds. Our role is to help organizations get a handle on this difference by cataloging everything currently in their system, so we created a tool for this and did some workshops where we help clients gather and organize this data.

We begin by capturing all of the interface integrations touching legacy systems that will eventually move to CloudSuite. It’s important to know the breach items and the business area to which they belongs, who owns the processes behind them, whether the objects require a file name, a description of what they accomplish, and what is the business purpose, if available.

Then, we want to categorize by existing technology. Is that a 4GL program? Is it a server-side script? Is it an IPA flow? When we have this information, we can link it out to any available requirements document. At this point, our team will come in and start our evaluation by examining each item that exists in the legacy system; we'll determine if it’s something that will cause development work as part of the CloudSuite project, or if it’s something that needs to be rebuilt or re-engineered.

During this phase, we will also figure out if it’s a delivered aspect that can be configured and turned on, potentially making it not worth the developmental effort. For those items in need of development, we want to start classifying them by the future state of the technology or tool that we will use to accomplish this item. Then, we give it a “t-shirt size” in terms of work effort – is this objective small, medium, or large? Once we've categorized all those items, we can pivot that data and decide how many IPA flows we need to develop by “size.” Those divisions will give us a good picture of the necessary resources and skills we’ll need to bring to our CloudSuite implementation, as well as the probable distribution of that work.

Learn About Pre-Planning

Back to Blog

Related Articles

The Key Deliverables of a CloudSuite Pre-Planning Engagement

Now let’s discuss some key deliverables you can  expect to receive out of this engagement. We have...

The Project Scope & Approach for an RPI Pre-Planning Event

Today we’re going to discuss the project scoping and approach. We begin with some as-is discovery...

The RPI Pre-Planning Assessment Executive Summary

All of the work we do in our pre-planning engagement, everything that we've been discussing so far...