Search the Elsmar Cove!
**Search ALL of Elsmar.com** with DuckDuckGo including content not in the forum - Search results with No ads.

Switching (Migrating) to a new QMS Software Package

Morlock

Involved In Discussions
#1
Hey all!

So, our current QMS software is being phased out by the provider, and we have identified and vetted (through free sandbox trials) a new QMS. This will be my first time being involved in something like this, and as a QA Manager, I will be very involved, so naturally I have some questions before I get elbows-deep.

Does anybody have any tips or tricks for switching from one QMS software to another to minimize the impact and to help make this transition as quick and painless as possible? Is there anything we should be looking at concurrently while we're doing this? For instance, are we able to cull obsolete PNs, documents, etc. at this time, or do we need to migrate those over, too? Is it better to revise the documents to reflect the new QMS software before or after migration?

We're ISO 13485, if that helps. To clarify, we're not looking to make any significant changes to any of our QMS processes, or content changes to any documents (outside of the obvious "how to create a document in [insert QMS platform here]" type documents), we're just migrating to a new QMS hosting platform.

Oh, and a curveball, Our current QMS and the new QMS cannot operate on the same OS, so we're looking at a very-literal "flipping-the-switch" thing, where we have to take one system offline before we bring the other system online. Although the IT guy might have a workaround for this...

Thanks all!
 
Last edited:

Morlock

Involved In Discussions
#3
Firstly, is this change documented in your management review? Secondly, do you have a plan? Clear responsibilities? Time line? Testing and expected results? Have you considered the consequences of the migration not going to plan? Plan "B"?
Thanks for the quick reply! We (management) just decided today to pull the trigger and place the order for the new QMS software, so what was on kind of a low simmer in the background now got moved to the main burner, but we're still in the pretty early phases. 1st step was to find a QMS software package we liked that checked the boxes for us. That's about as far as we've gotten at the moment...

-The migration is on the MR Agenda (happening later this week), but we're a small company, and management is already well aware of the situation, and is updated frequently;​
-I have started putting together a plan for a plan, but any advice regarding specifics would be appreciated;​
-Most of the responsibilities lie with me and the IT guy at the moment, but clearly defining and assigning them would be a great tool for the project;​
-Our time line at the moment is simply a window between once we get the new QMS software online, and when our licensure for the old QMS software expires;​
-From what we tested via the trials, all of the structure is there in the new QMS platform. It'll just be a matter of importing/inputting employee names into the "employees" section, equipment into the "equipment" section, gauges into the "gauges" section, assigning PM and cal. dates, uploading docs, etc;​
-Plan B at the moment is to continue with the old QMS software, without support for it (it's locally hosted).​
 
Last edited:

yodon

Staff member
Super Moderator
#4
You're probably in for a thrilling adventure! :)

I would probably advise against your Plan B. At some point, something will occur (OS upgrades, backend database engine upgrades, etc.) that will likely prevent the system from working.

I would, though, probably plan on keeping it online for access to what's in there. Even if you migrate things to the new system, it's almost certain that historical information and relevant metadata (e.g., data related to e-signature manifestation) will not be migrated.

As the old system (as well as the new system) represents software used in implementing the QMS, it should have been validated. You should validate the new system prior to going full online.

If you are migrating information (and I presume you'd pretty much have to), you'll want to validate the migration as well.

You likely have things in process in the old system so you'll need to plan on what to do with those (cancel / start over on the new system, push through to completion on the old system, etc.).
 

Morlock

Involved In Discussions
#5
Thrilling, indeed. Yaaaaaaay...

We will have at least one station online with the old OS and old QMS platform (the new QMS platform requires a newer OS, so there's that little curveball, too) in case things do go south, and we will keep it up and running until we are sure that everything has been successfully transferred over.

The old system was validated, and the new system will be validated. The QMS platform is already ISO 9001/ISO 13485/FDA 21 CFR Part 820/FDA 21 CFR Part 11 compliant, which should help, and we've been playign with a sandbox version for a bit now, so we're a little familiar with it. Any tips on the best way TO validate the new system, and how to do it effectively and efficiently? How would you validate the migration? Just compare the input and the output, or does it need to include the migration process?

As of right now, we're planning on a hard break. Anything already distributed with the old system will continue with the old system, anything new from "INSERT DATE HERE" will be with the new QMS/documentation.
 

yodon

Staff member
Super Moderator
#6
I wouldn't think it would be necessary to validate the migration process. I would document your decision in a validation plan covering both what you intend to do for validating the system and the data migration.

Since you validated the old system, you should be able to use that to jump-start the validation of the new system. Remember that you only have to validate for your intended use and not the whole system. For the Part 11 aspects, the system is designed to support compliance; however, you should demonstrate that, in fact, you are using it in a manner that is compliant. For example, if you gave everyone admin access, you would likely lose control of aspects such as audit trail.

I've yet to come across an auditor / inspector that really delves deeply into these validation records. Showing due diligence is really the key.
 
#7
Hey all!

So, our current QMS software is being phased out by the provider, and we have identified and vetted (through free sandbox trials) a new QMS. This will be my first time being involved in something like this, and as a QA Manager, I will be very involved, so naturally I have some questions before I get elbows-deep.

Does anybody have any tips or tricks for switching from one QMS software to another to minimize the impact and to help make this transition as quick and painless as possible? Is there anything we should be looking at concurrently while we're doing this? For instance, are we able to cull obsolete PNs, documents, etc. at this time, or do we need to migrate those over, too? Is it better to revise the documents to reflect the new QMS software before or after migration?

We're ISO 13485, if that helps. To clarify, we're not looking to make any significant changes to any of our QMS processes, or content changes to any documents (outside of the obvious "how to create a document in [insert QMS platform here]" type documents), we're just migrating to a new QMS hosting platform.

Oh, and a curveball, Our current QMS and the new QMS cannot operate on the same OS, so we're looking at a very-literal "flipping-the-switch" thing, where we have to take one system offline before we bring the other system online. Although the IT guy might have a workaround for this...

Thanks all!
Take a look at 6.3 planning changes, risks, people, etc.
 

Ninja

Looking for Reality
Trusted
#8
New software...good luck...

Test, test, test, test, test...and then test.
In your planning, don't forget key people to be trained to the new system...and access privilege setup.
Then test it again.

Good idea to keep the old system up for as long as possible...no matter how much you test it, you'll hit snags...
 
#9
New software...good luck...

Test, test, test, test, test...and then test.
In your planning, don't forget key people to be trained to the new system...and access privilege setup.
Then test it again.

Good idea to keep the old system up for as long as possible...no matter how much you test it, you'll hit snags...
Agree with ninja, additional, consider a timeframe for the software developer to make changes if necessary, and final retesting.
 
#10
Hey all!

So, our current QMS software is being phased out by the provider, and we have identified and vetted (through free sandbox trials) a new QMS. This will be my first time being involved in something like this, and as a QA Manager, I will be very involved, so naturally I have some questions before I get elbows-deep.

Does anybody have any tips or tricks for switching from one QMS software to another to minimize the impact and to help make this transition as quick and painless as possible? Is there anything we should be looking at concurrently while we're doing this? For instance, are we able to cull obsolete PNs, documents, etc. at this time, or do we need to migrate those over, too? Is it better to revise the documents to reflect the new QMS software before or after migration?

We're ISO 13485, if that helps. To clarify, we're not looking to make any significant changes to any of our QMS processes, or content changes to any documents (outside of the obvious "how to create a document in [insert QMS platform here]" type documents), we're just migrating to a new QMS hosting platform.

Oh, and a curveball, Our current QMS and the new QMS cannot operate on the same OS, so we're looking at a very-literal "flipping-the-switch" thing, where we have to take one system offline before we bring the other system online. Although the IT guy might have a workaround for this...

Thanks all!
So how did the transfer work out?
 
Top Bottom