Skip to main content

Hello IFS Community!

 

I’m assessing a strategy for a legacy ERP migration into a PRODUCTION IFS APPS 10 (UPD16). This is a multi-tenant  instance (many companies are running on this IFS instance). There is already one company operational and I am migrating company #2.

My question is this: we are considering two strategies

  1. Migrate this new company (let’s call it, company “A”) into PRODUCTION where the current company (company “B”) is operational. Do the migration and QA work directly in PROD. Once the GO-NO GO decision is made (if GO) then just start using PROD with no further delays. In this approach there is no freeze period for company “B”
  2. Migrate this new company in a staging environment that we will clone off PRODUCTION (so all of company’s “B” data is there), freeze PROD during migration (tell users of company “B” site is off-limits for now). Do the migration and QA work there (in staging). Once the GO-NO GO decision is made (if GO) then clone back the staging into PROD and unfreeze PROD for Company “B”.

Obviously approach “1” is more convenient for company “B” as they will be able to use the PROD environment during migration (performance can be an issue as both OLTP work from operations and BATCH work from migration compete for resources, but I’m leaving those considerations out of here for simplicity’s sake). The reason why approach “2” was suggested is because rollback would be way easier there, no need to perform a backup just before migration starts nor there is a need to restore that backup should QA work would deem for any reason a NO-GO.

Has anybody done Legacy to IFS migrations to environments where other companies are up and running? if so, what strategy worked for you?

Thanks!

There are several steps involved here. 

 

First you will need to do a data mapping/translation exercise from the legacy ERP to IFS

Next, Perform a gap analysis of IFS required data and populate with values. 

Perform several test migrations and subsequent unit testing to ensure the migrated data achieves a functional IFS Company

Once 100% happy then migrate into PROD/LIVE

 

There is simply too much involved to go straight into PROD without prior testing.

Hi WyLeeLeW

 

Maybe I didn’t state my question properly but your reply doesn’t answer my question. We are certainly aware of everything you mention on your post and we are definitely NOT going straight into PROD without prior testing. This is a large endeavor with many teams involved and testing started more than a year ago (with several passes already under our belt). We have crossed al the “T’s and dotted the I’s (gap analysis, mapping exercises, run logs, contingency plans, etc (the whole shebang...).

 

My question is strictly related to a GO-LIVE approach AFTER everything was tested and we are confident we have solutioned the migration the way we wanted. This is purely a question specific to the scenario described above (migrating to a multi-tenant environment with a company already in operation). In other words: when you have an IFS instance in PROD with a company already running (I called this “company B”) whether cloning the PROD environment into a STAGING and doing the migration of the new company (“company A”) in that staging environment makes more sense than a Production GO LIVE exercise where you migrate the new company into PROD.
 

I personally see the advantage of cloning out and cloning back in (before and after the migration of the new company) especially from a disaster recovery standpoint. For example: if you clone out on a STG environment on Friday evening and during your weekend (when you are migrating) you decide a NO-GO because something with the migration of the new company went wrong, you simply cancel the “clone back” exercise and everything will look right for company “B” on Monday morning. On the other hand rolling back a migration directly to PRD for the new company can be difficult if you need to roll back because of any contingency.

 

The advantage of a migration for the new company directly in PRD is less disruption to Company “B” (already operating) because there is no need to freeze them.

 

Makes more sense now why I’m asking that?

Ah that makes sense now. 

I would say you are at a point of no return really. whichever way you look at it the proof of success will be what happens when users start using the environment in anger. 

I’d do a cut over weekend into LIVE but take a backup of LIVE before starting so you have a roll back point. In experience the issues will tend show days/weeks after migration anyway so the roll back window will have passed.

I hope that helps

I agree with the fact that issues tend to show days/weeks after migration. I heard one horror story from a colleague regarding that when the company he was working for was not able to rollback, yet moving forward was almost impossible as well.

Having said that, not so long ago we had a migration exercise in production where the leadership team decided to NO-GO (the details are long and boring but conditions were not adequate to proceed) on the migration weekend so the rollback was possible.

In a scenario where a NO-GO occurs as part of the Migration Plan, rolling back with a backup is possible. Having said that, if you clone in a staging environment and do you GO LIVE there, and there is a decision to NOT proceed, a rollback is as simple as not cloning your STAGING into PROD as the last step. I have never migrated this way but I can see the value in approaching a go live in this way

  1. Clone PROD into STG on Friday (PROD starts FREEZE period)
  2. Run your whole migraiton in STG (Saturday/Sunday)
  3. Decide (GO/NO-GO) (Sunday evening)
  4. If GO, Clone STG into PRD (UNFREEZE with Cloning), if NO-GO simply do nothing and leave PROD how it was before the original Clone on Friday (UNFREEZE without Cloning)

I don’t know if someone in this community was challenged to think of a migration like this… I’m just curious if there is something that would make one approach (or the other) impractical.

Reply


Terms & ConditionsCookie settings