Migration projects: Incorporating the ‘old’ into the ‘new’

I’m currently in the midst of a migration project from an obsolete distributed control system (DCS) and the biggest challenge is convincing the plant that the team has done a perfect conversion in spite of the plant also wanting to take advantage of the latest thinking in controls—in particular the improvements in Batch. This is not unique to this project.

Most migration design decisions revolve around ensuring that the new system can at least meet production targets of the old system the day you turn it on. If you actually deliver some improvement then that’s just icing on the cake. The challenges in accomplishing this are the plant seldom actually knows just how the old system does, what it does, and the old code is seldom well documented or is poorly written in the first place.

In this case, we are attempting to utilize some prebuilt control modules supplied by the manufacturer of the system that do not lend themselves to including comments in the code, so I don’t actually expect the end product to be that readable during a future migration. The supplier has documented how their modules work, but that doesn’t touch our implementation. These calculations, for instance, are still difficult to understand because they include factors that aren’t explained in the original code. So, like me, anyone coming after me is going to be as puzzled as I am as to how they were derived. When I execute the code, I get the same results they do, but if something underlying the development of those factors changes, I have no idea how to correct them. I also have no idea how to even guide the next person to work on them.

Utilizing standardized code and make doing projects across an enterprise consistent it doesn’t ensure that the resulting code will actually do the job in an identical manner to what it is replacing. This isn’t to say that standardized code modules are a bad thing but they don’t do it by themselves. A lot of work has to go into developing the conversion and the bulk of that is just to understand how it works now. There are no shortcuts to getting that understanding just lots of hard work.

How do you ensure that you know just how your system works so you can direct your next migration?

This post was written by Bruce Brandt. Bruce is a principal engineer at MAVERICK Technologies, a leading automation solutions provider offering industrial automation, strategic manufacturing, and enterprise integration services for the process industries. MAVERICK delivers expertise and consulting in a wide variety of areas including industrial automation controls, distributed control systems, manufacturing execution systems, operational strategy, business process optimization and more.

Do you have experience and expertise with the topics mentioned in this content? You should consider contributing to our CFE Media editorial team and getting the recognition you and your company deserve. Click here to start this process.