Moving to the cloud is exciting, but it’s also a big lift. And the way you prepare shapes how successful the project will be. That’s the focus of this episode of RPI Tech Connect, where host Chris Arey sits down with Ken Foley, VP of the Infor Practice at RPI, to talk through the prep work that makes all the difference once a migration kicks off.
They dig into the questions every team should ask early, from figuring out what functionality you really need, to deciding between a phased or big bang rollout, to planning how data and tenants will be handled along the way. Ken also shares stories from real projects, lessons learned, and practical advice to help you head into a cloud implementation with confidence.
If you’re considering a move to the cloud or your project is already underway, this conversation is a roadmap for starting smart and finishing strong. Interested in listening to this episode on another streaming platform? Check out our directories or watch the YouTube video below.
Meet Today’s Guest, Ken Foley
Ken Foley is a Professional Services leader with more than 25 years of experience in enterprise software development, implementation, and support. As Vice President of the Infor Practice at RPI Consultants, where he has served for nearly seven years, Ken helps clients prepare for and execute successful cloud transitions by combining proven implementation methodologies with best practice business processes. He is passionate about helping organizations get the most out of their technology investments and ensuring long-term value through thoughtful planning and support.
Before joining RPI, Ken spent over a decade at NTT DATA Services in roles ranging from Senior Solutions Architect to Senior Director, where he guided large-scale enterprise software projects across diverse industries. His depth of experience, combined with his commitment to customer success, makes him a trusted advisor for organizations navigating complex ERP and cloud transformations.
Meet Your Host, Chris Arey
Chris Arey is a B2B marketing professional with nearly a decade of experience working in content creation, copywriting, SEO, website architecture, corporate branding, and social media. Beginning his career as an analyst before making a lateral move into marketing, he combines analytical thinking with creative flair—two fundamental qualities required in marketing.
With a Bachelor’s degree in English and certifications from the Digital Marketing Institute and HubSpot, Chris has spearheaded impactful content marketing initiatives, participated in corporate re-branding efforts, and collaborated with celebrity influencers. He has also worked with award-winning PR professionals to create unique, compelling campaigns that drove brand recognition and revenue growth for his previous employers.
Chris’ versatility is highlighted by his experience working across different industries, including HR, Tech, SaaS, and Consulting.
About RPI Tech Connect
RPI Tech Connect is the go-to podcast for catching up on the dynamic world of Enterprise Resource Planning (ERP). Join us as we discuss the future of ERPs, covering everything from best practices and organizational change to seamless cloud migration and optimizing applications. Plus, we’ll share predictions and insights of what to expect in the future world of ERPs.
RPI Tech Connect delivers relevant, valuable information in a digestible format. Through candid, genuine conversations and stories from the world of consulting, we aim to provide actionable steps to help you elevate your organization’s ERP. Whether you’re a seasoned professional or new to the ERP scene, our podcast ensures you’re well-equipped for success.
Tune in as we explore tips and tricks in the field of ERP consulting each week and subscribe below.
Transcript
Chris Arey
This is RPI Tech Connect. I’m your host, Chris Arey. Today, we’re going to be focusing on a crucial step for organizations that are planning a move to the cloud: preparation.
Too often, we see companies waiting until late into the process to think about the big picture requirements. Today we’ll talk about what you should be considering early, before the project even begins.
Joining me today is Mr. Ken Foley, VP of the Infor practice here at RPI. Ken, pleasure to have you on the program, sir. Where are you calling in from today and what can you share with us about yourself?
Ken Foley
Thanks Chris. I’m in North Reading, Massachusetts. It’s a suburb about 15 miles north of Boston and it’s a beautiful sunny day today, although we’re coming to the end of a beautiful season. But anyway, we are here, happy, and ready to go.
Chris Arey
Thank you. I appreciate that. You have to enjoy the weather while you can. But yeah, like you said, let’s just go ahead and get right into it here.
Starting big picture here, sometimes customers focus on the technical and contractual details, but what are some of the more like bigger strategic considerations they should be thinking about the move to cloud?
Ken Foley
Yeah, there are several things that I think would behoove a customer to consider before making this move.
We’ve had some experiences where people were not so prepared, which caused problems at different points throughout the process. That said, I want to share my experiences with folks out there that are looking to move to the cloud so they can avoid them.
Step one is to make sure you understand your application requirements and the functionality that you need to bring over. Whether you’re coming from another product altogether that’s not Lawson to Infor CloudSuite or moving from Lawson, you want to make sure that what your internal customers really need to operate a business is covered.
And just don’t, you know, if you’re coming from Lawson to Cloud Suite, just don’t assume it’s going to be there because it’s an upgrade. A lot of it is similar, but there are some differences. So, you just want to make sure you get your bases covered.
Also, there’s a lot of new functionality in Cloud Suite, so you want to make sure that you’re aware of what’s available and have an idea what’s going to pique the interest of your users.
Once they’re shown something and they love it, they’re going to want to include it in the implementation. If you haven’t thought through that or acquired the appropriate licenses, it’s going to cause problems when you’re trying to basically go back to the table, add items to the scope and so forth.
You may have been at that stage following contracting and all that. Not only does the nature of the subscription change, but the estimates themselves could change as well.
Infor is going to provide you with a software order form. It’s going to list all these SKUs, all the subscriptions, software descriptions, and license restrictions.
As well as the number of users you have, how many licenses you have, how it’s licensed: is it by employee, the enterprise, or by platform, and then the support levels associated with it.
I would make sure that regardless of who you select as an implementation partner, whether it is Infor themselves or a partner like RPI, you review the list and have a full understanding of what you’re getting for functionality for each of those items.
Then, you can reconcile that back to the expectations that you guys have going in. Like I said before, it’s much easier to get the list correct upfront than having to backtrack after contracting to add and remove items.
It also affects your subscription and implementation costs. I would also suggest you review the published Infor Software as a Service Delivery Guide. It provides you with a detailed explanation of subscription services that are delivered by Infor.
It clearly outlines roles, responsibilities and things such as: what does disaster recovery high availability look like? Release management, change management, incident management, security, and the tools that they’ll be using to support you.
And then when you’re talking with Infor, when you’re doing the order form and finalizing it, just make sure you understand what you’re getting from the Cloud Operations team during the implementation project, whether it’s services that are included in the subscription or there’s additional fees.
Find that out ahead of time and make some good decisions there. That’s scope. Then we get into phasing and scheduling, which comes up all the time too.
In terms of the phasing, you’re going to either go big bang or a phase rollout? Those are your options, right? So, when you’re determining this, you need to understand the organization’s capability to handle large projects.
Is this the biggest project you’ve undertaken, or have there been others? It is important that you know how your organization works and whether the people involved in these projects can handle the project along with their normal day-to-day work, because you have your existing system that you must manage as well.
Understanding that. Understanding the time requirements. Responsibilities expected from you guys during the project can be covered during a planned quarterly meeting. This is a good time to talk with whoever you’re selecting for an implementer so they can share with you what their expectations are of your project team during the project.
The project length, planning phases, getting support to manage your current system, and other things like that will help you make decisions on how you’re going to manage the demand of your staff during the project.
But your choices regarding scheduling will have cost-related impact on the project. When you’re considering, do I do big bang, do I do phased, multi-phased and all that, you must take those things into consideration also.
Working with the implementer on making that decision, helping you with pros and cons is good. So that’s the phasing. And then we have data disposition, which a lot of folks don’t really think about. So that’s like what’s happening with your data after the project, right?
Or even during the project. Start by understanding your data retention policies. What must exist after the project? Are you going to be purging any data, which we normally don’t do.
There are some clients that will purge data that’s outside of that scope according to their retention policy. That happens.
What’s the data that’s going to be migrated or converted into the new system, and whether historical data is getting converted. So, the new codes, the new account setup, whatever it is, how are you mapping that into the new system?
And then what is not going to get migrated and converted but you need to exist, right? That’s the archiving process. Where’s that going to live after the project, right? How are your users going to access it? How are you going to secure it? All those types of questions.
And the biggest thing we’ve been finding more recently, it’s not just about the data that are in rows and columns, which is the structured data, right?
There’s a ton of unstructured data, like attachments, contracts, purchase orders, other types of documents, invoice images, and all that stuff, which is probably in these other systems right now.
We have IDM and then CloudSuite, so are you going to migrate all that data to IDM and then attach it when you convert it over? For the data that’s not actually converted and going to live in our archive system, what are you going to do with that?
Right? Thinking through these questions ahead of time will also help you with the contract, because there’s an archival solution you must think about. Then understanding, am I going to go through the data migration factory or are we going to do an actual conversion depending on where you’re coming from, how much you bring in over and all that. Right?
And then the last thing, which is Tenant Strategy, which is based on all the answers to the previous questions I just mentioned, right? So, you can determine the number of tenants you’ll need based on your project. Product scope and phasing are big determining factors of that. So, there you go in a nutshell.
Chris Arey
Thank you, was a lot of great content there. I have a couple of follow-up questions for you. Let’s go back to the application scope, starting from the beginning there. I imagine that you want to get all that taken care of and like solidified early on, because if you want to modify it later, it gets more expensive, is that right?
Ken Foley
Sure. Well, it could cause a little problem when figuring out, is it at a cost? How does that affect my implementation? Does it affect the implementation schedule? So, depending on what you’re adding, could that create some extending the project a bit? Because it’s all based on what you’re implementing and the scope of it when we try to schedule.
Chris Arey
Okay, and obviously when you add in things later, it inevitably probably lengthens.
Ken Foley
Yeah. Especially if you’re adding things after we’ve already had a testing cycle and all that, you’re introducing a little bit more complexity. Decisions could have been made that might have to be changed because of what you’re adding in and so forth.
Then you have to kind of go through that discovery. If you’re doing it after discovery is completed and all that, it just adds a little bit of confusion to things. Try to figure out your scope ahead of time.
Chris Arey
You really want to spend the time upfront and early to be confident and establish your application scope and minimize changes.
Ken Foley
Yep. It’s always best to have as much covered upfront as possible.
Chris Arey
Okay, thank you. During my time here at RPI, we’ve talked a lot about the difference between the big bang approach and the phased approach. Though it’s certainly situational, have you found one approach that’s better than another, or how do you approach that?
Ken Foey
It is situational. Yeah, it really depends on whether you have a customer who’s used to large scale projects and has the resources to spend on the project and is not tied to day-to-day activities.
In HR that would be like if you have an HRIS group that is helping the HR folks with data analytics but also works heavily on projects in terms of implementations or just developing new functionality for the HR team. If you’ve built that way and have project teams that move from project to project, then a big bang is probably not a big deal for you.
With HRIS, you will have super users, HR people that are responsible for the function that have to be involved. Obviously for decision-making purposes, that makes sense. But if you have HRIS supporting them, they can handle working with the consultant on configuration and stuff like that.
But in the event where they don’t have some of that in place, you’re depending more on that business function to be involved in the project, and there tend to be limitations in terms of when they’re available and all that.
Payroll is a perfect example. If you use a bi-weekly payroll system, they must run their payroll, so you only have them available every other week. You must consider the availability of the people to be able to handle the project.
In those cases, sometimes they’ll rather elongate the overall project so it’s more of a slower roll. We’ve had that happen recently with several cases. Or you phase it out.
If you have people that are involved in the financial supply chain area of the company, but for whatever reason they’re also involved in payroll or HR, if you’re doing a big bang and everything’s happening at the same time, they just may not have the capacity to handle it all.
Right? So, you will decide to do that. Other things they could do is they could implement the HRT or what people refer to as GHR but then hold off on talent acquisition and some of those other modules.
The stuff that’s on the fringe can wait until a phase two. Let’s get the core functionality first.
Chris Arey
Got it. So, if I’m hearing you right, this question about whether to do a phased or big bang approach is dependent on like resource availability.
Ken Foley
There’s many ways to skin the cat. Yeah. Yeah.
Chris Arey
Got it. If I’m hearing you right, this question about whether to do a phased or big bang approach depends on resource availability.
Ken Foley
Situational. Yeah, a lot of it has to do with that. And it’s not going to be budget-related, because when you’re acquiring the subscriptions, you’re buying everything upfront, no matter how you’re going to implement and phase it.
You need to have tenants in place when the time comes.
Chris Arey
Okay, yeah. I have some questions for you about the tenant strategy, but before I get there, one more for you here about data. It’s a very important topic, something some people may need to spend more time thinking about.
I’ve heard that sometimes there’s a challenge with organizations wanting to migrate too much data. What is your recommendation or approach to how to determine when the cutoff point is?
How do they approach that?
Ken Foley
Well, first off, want to say, Infor is not going to limit, you right? If you’re using their data migration factories, coming from Lawson onto Cloud Suite, they’re not going to limit you, right?
They will have best practices and suggestions. One of the things you have to decide is how long you are going to really need the history?
We would like to say, bring over into your new system what you’re going to be touching a lot, right? We don’t want the user to have to go to an archive system every day to get something. That’s not what we’re trying to do. We’re not trying to make their lives harder.
If it’s something that they’re frequently touching, then bring it over, right? The challenge though is when you are bringing over data from 20 years ago is one, how clean really is it, right? Two, you now are going to have to consider all the master data that’s associated with that data from 20 years ago, right?
Accounts, customers, vendors, all that stuff. If you are bringing over like an invoice record from 20 years ago on a vendor, you haven’t used it in 15 years, right? Now you have that vendor in your master. Even if it’s inactivated, it’s still there. And you’re building a brand new, beautiful system.
Chris Arey
Do you really need that?
Ken Foley
Why would you want to mess it up with stuff from 20 years ago? You really want to be reminded of that? And then if you’re talking about auditing, it’s like half the time, I would think an auditor is going to want to see the transaction in the state it was created, right?
That’s where archive comes in because it keeps everything in the original state in an archive. I would be very careful about what you decide you want to bring over and convert or migrate into the new system.
Again, I think the premise should be if the users have to see it daily or frequently, then that should be the decision point of when you bring it over. So how far back do you really have to go? Does it really have to be two years ago? And there’s some things that, you know, stay open for a long time.
For example, I hear the example of contracts all the time. Contracts can be open for 10 to 12 years, you know? So I totally understand that, but that should be a conversation we have upfront.
Chris Arey
Sure. Got it. I like that rule of thumb that you kind of established there. How often is this data really going to be interacted with?
Ken Foley
And Chris, you must understand that this is dependent on the organization too, right? A fiscal year’s worth of data may not be a lot for an organization where for another organization, it’s millions of records, right? So, the other consideration is how long is it going to take to get this over to the new system? How much time do you want to spend with production down as you complete that final migration, right?
So how much time do you have? As you make those decisions, and we go through the project, we can kind of determine how long it is really going to take us to get that data converted or migrated.
Chris Arey
That’s important. There are so many things to consider and think about as you’re preparing for implementation. For those of you listening in right now, these are the questions you need to be asking yourself as you’re getting ready for this kind of transition.
There is no shortage of things to think about. Now you mentioned earlier that all these different topics, the application scope, the phasing and this data element all ladder up into this tenant strategy. Can you expand on that a little bit more?
Ken Foley
Mm-hmm. Sure. Yeah, so Infor released a brilliant document a few years back that assisted in planning strategies for different scenarios. Phased implementation, full suite, payroll involved, stuff like that. They introduced that to me a couple of years ago.
I was like, this is fantastic, because it makes sense. That strategy tries to mitigate lost time and effort due to unplanned data refreshes during the project. Refreshing data can really cause a lot of downtime if it’s unplanned.
It also helps us to kind of manage what are the activities that should be happening in each of the tenants as we’re going through the implementation. We need to enforce discipline when managing those activities that are occurring in each of the tenants.
So, for example, a software development lifecycle, right? Development should be happening in a particular tenant that’s identified up front, right? Only development happens in this tenant, and we’re never going to develop in another tenant or cut corners.
We’re going to develop in a certain tenant and we’re going to unit test in that tenant, meaning development unit test.
Chris Arey
Okay. Yup.
Ken Foley
We’re going to make sure that what we developed is meeting the requirements that we gathered and is developed based on the design that we documented for the client. Once that’s figured out and we’ve unit tested and we’re happy with that, then that will then get deployed over to a testing tenant. That’s where our testing cycles will occur.
And then we also have another tenant that we will consider what we call pristine. That is the basic build, how the software is configured after decisions have been finalized or we’ve drawn the line on something.
Chris Arey
Got it.
Ken Foley
We’re going to go this way with it, right? So we’ll go that way for a bit. And then obviously we test and validate and all that. And then, you know, if the changes have to be made, we make the changes.
Eventually it’s going to be in this pristine build. Prior to the testing cycle, we’re going to copy that pristine build into the test tenant.
And then we make sure all our development items are in there and all that. We then have a tenant that we’re ready to test in, in a cycle, whether it’s unit testing, system integration testing, user acceptance testing, mock testing, right? That type of thing.
For a software development life cycle and then this whole testing cycle I’m talking about, we have a strategy and the tendency to keep things in line because what happens? We have data that refreshes.
Well, when does that happen? Where’s it coming from? What are the steps for that? Right. Thanks to our planned strategy, we don’t pounce on each other.
Another example is parallel payroll testing. Now we have a payroll parallel but remember the parallel is going to go on after the normal testing cycle. So, we go through a system integration test, right?
Parallel may happen after that because they’re going to do some normal payroll testing in the testing tenant, but it’s going to take some additional time to run through a full payroll cycle end to end and then do validation to make sure the balances are correct and all that.
All the paychecks look good. You know, all that stuff. takes time, but I want that testing tenant as soon as possible because we have to get ready for the next test cycle, which in this case would be UAT. And it takes time to build and all that.
Because of this, we suggest that you have a separate tenant for payroll parallel, so they can take as long as they need while we’re rebuilding the other tenant for the next testing cycle.
Here’s how we do that. You have the data for refreshing, right, so you’re building the test tenant for the regular testing cycle. Once all the data is converted or migrated, data is validated, you know, you’ve got to make sure it’s good.
When all that’s said and done, then you make the copy to another tenant for the payroll parallel. And that’s off to the side. Then you continue with your testing and then the payroll team can validate their, you know, the parallel. But now we can tear down the original test tenant when testing is done there so that we can start the build for the next round.
What does that do for us, Chris? It shortens the timeline of the project, all right? Because I’m not waiting to build for UAT until after parallel is done, which could be weeks, right? So, we save a ton of time. And that’s why I suggest that clients understand their scope, their phasing particulars and all that. Phasing I didn’t even get into, because you’re going to be live in one part of CloudSuite and not the other.
As a result, you need to have a production live tenant for where you’re on live with, and probably another tenant for testing, right? Because things will change after you go live or things have to be tested because you have to fix something.
You need to have two tenants for your live system. And then you need the three for your regular project that you’re still doing. And usually that’s like HR and payroll, so it could easily be five.
It just depends. Talking with your implementer will help in that because they can tell you, OK, here’s the methodology. This is the approach we’re taking. You’re doing phase. This is what our timeline looks like, and this is what you think you should have to make sure we keep it as efficient as possible. So long-winded, but that’s the deal.
Chris Arey
No, fantastic examples. It really shows how much these other steps we talked about influence the tenant strategy and why starting with those is a good place.
It forces you to be engaged throughout your testing process as certain things are going live at different times. You really have to think about the tenant resources you’re going to have available for those exercises.
Ken Foley
Yeah. And I didn’t even mention pre-prod, so.
Chris Arey
For those of you listening in, there’s a lot to consider. A lot to think about when moving to the cloud, though it has considerable benefits for your business. There’s a lot to think about. It’s not an overnight project. I really appreciate you sharing these insights here, Ken. We’re getting close to time, but as you know, I always like to ask my guests before we wrap up if they could share one piece of advice for those listening in today.
You know, if you’ve got 30 seconds elevator pitch, what’s the one thing you want people to take away from this?
Ken Foley
Yeah, preparation is key here, folks. And it’s not simple, right? It takes some time, discussions and all that. If you decided on your implementer before you finish up contracting with Infor and your implementer, you want to lock down a lot of the stuff ahead of time so that you just don’t have surprises during the project.
We’ve had a couple of clients that have really done a good job of that preparation and have asked us a ton of good questions. Those projects will be successes because of the preparation they put in.
Chris Arey
Thank you. Really great discussion. So many valuable insights for me and for those of you listening, hope you share the same sentiment.
If you have any questions about today’s discussion, you want to learn more about preparing for a move to the cloud, we’d love to hear from you.
You can contact us at podcast@rpic.com. Again, that’s podcast@rpic.com. This has been RPI Tech Connect. Thanks for stopping by, and we’ll see you next time. Thanks Ken.
Ken Foley
Thank you.
