Transferring a validated software platform to a virtual server

[kisxena]

Hello:

Last year I spent many months validating our 3rd-party documentation software. Now, the IT department wants to move it from the Oracle platform to a virtual machine system (VMS).

My question is, how in-depth of a validation do I need to create and perform?

The IT department wrote a very skeletal virtual plan which only outlines performing functions of generating an ECO, creating a part number, verifying CCB review can be performed, release of the ECO and opening an attachment.

I'm not an expert in ISO and QSR requirements when it comes to transferring an already validation software system to a virtual platform.

Any advice is greatly appreciated.

Thanks,

-Renee

 

[Marc]

I moved this thread to the Software Quality Assurance forum. We don't get too many software people here, but hopefully someone can help.

 

[Kevin Mader]

Marc,

I'll take a shot, but it is late so this may be in parts.

Renee,

My experience is that the IT folks understand very little about validation from a Part 820 or Part 11 perspective. It's difficult to say for sure if the plan provides an adequate validation strategy, but using a risk based approach, you might significantly reduce the amount of work needed. For instance, it is not uncommon to use a different client server to verify and validate software before loading it into the production environment. Here, you would need to demonstrate why the test client is similar the production client. This is done all the time. You might want to develop your rationale around the level of testing needed around this concept, develop your validation strategy in the hopes of minimizing your work. I'm skeptical of the IT plan - some of the ones I've seen are flimsy and poorly concieved because they aren't familiar with the regulatory requirements and because many IT professionals I've worked with are adhoc testers, creating and validating in the same effort. Poorly established requirements are largely to blame as most often its experimenting while designing only nobody knows when to stop designing and when to start validating. It makes the strategy and tactics of validation difficult and sometimes impossible.

Well, something to get you started. There are others here with good experience around your problem. Hopefully they will chime in too.

Regards,

Kevin

 

[kisxena]

Thanks Kevin for your info. Hopefully others will chime in as well.

You're right, IT does not fully comprehend 21 CFR Part 11 but we try to educate them.

 

[Kevin Mader]

kisxena,

Questions for you -

Does your QMS have established procedures around QMS software validation? If you do, there may be some internal guidance there that can help you.

When reviewing your original Validation Plan, are there aspects in it that can be leveraged? I'm assuming that many aspects can be rationalized as to why you wouldn't have to revalidate them.

Regards,

Kevin

P.S. I love the weather in San Diego! I generally get to pass through your city a few times a year.

 

[BradM]

I think Kevin covered this quite sufficiently. Good to see you around, Kevin.

First, there should be a written plan that entails what differences are expected. The designer of the validated program should be able to help provide some caveats to the differences that will occur when switching platforms.

I would think a general testing plan should focus less on the actual functionality within the application, and more what happens when it interacts on whatever platform it has been placed.

For example, will the software time out the same, will the reports look the same, will access to the platform be the same, etc. Even after any validation work has been completed, I would recommend keeping a good change control, issue system so that you can capture when something occurs, and clearly identify the applied solution.

Just some random thoughts.

 

[kisxena]

Thanks Brad!

 

[Kevin Mader]

That's good advice Brad. Asking the architects about the differences and challenges to be faced should help tease out the test plan requirements and help to establish/adjust the acceptance criteria.

I don't get back here as often as I'd like to - darned kids, but it's good to contribute when I can. Thanks for chiming in.

Kev

 

[arin_23]

Hello:

Last year I spent many months validating our 3rd-party documentation software. Now, the IT department wants to move it from the Oracle platform to a virtual machine system (VMS).

My question is, how in-depth of a validation do I need to create and perform?

The IT department wrote a very skeletal virtual plan which only outlines performing functions of generating an ECO, creating a part number, verifying CCB review can be performed, release of the ECO and opening an attachment.

I'm not an expert in ISO and QSR requirements when it comes to transferring an already validation software system to a virtual platform.

Any advice is greatly appreciated.

Thanks,

-Renee

Dear Renee,

I could not get the clear picture from your problem statement, is it a legacy system you possess which needs to be re engineered? Or it is simply moving from one technology to the other?

If you talking about validation then I assume you are the end user of the software.

Lifecycle models are going to be different based on the different kind of situations. For case 1 the re-engineering lifecycle model shall be followed, while in case 2 it would probably be a modification / enhancement lifecycle where the standard SDLC would be followed. Based on the lifecycle models your testing strategy shall vary.

For case 1 there would be significant changes to the project artifacts and test cases shall be redefined, whereas for case 2 there might be new set of test cases developed based on the URS and followed up by a detailed requirement analysis.

In both the cases however the base lined SRS is the artifact which would give clear indication of the testing strategy. In my opinion before jumping onto the UAT of the final application ; carry out the validation in a staggered manner, and in each stage namely SRS, HLD, LLD, Module-wise code review and finally UAT of the application. Please make it a point to validate the product documentation as well.

The URS shall be your starting point and the Application successfully running in the production environment is the last step. In between strict configuration control has to be exercised for all CR’s as there should not be anything which is missed out due to loose configuration control mechanism.

This kind of staggered validation technique shall enable you to have full work knowledge about the product.

Regards,

Arin