데이터 마이그레이션 (Data migration)

DI 업무를 시작하게 되면, 어떤 순서로 시작해야할지 감이 오지 않는데요.

그러다 보니 이것 저것 급한 순서대로 (Inspection 지적을 피하기 위한) 일을 하게 됩니다.

 

그러다 보니, 각 영역에서 어떤 데이터가 만들어지고,

어떻게 흘러가게되는지 (Data flow) 를 정의하는 게 중요하지만 놓치기 쉬운 것 같습니다.

Data flow 만큼 중요한 데이터의 분류 (예: 중대한 데이터/Critical data, 덜 중요한 데이터 Major/Minor data) 작업도

결국 기본적인 조치 (Audit trail / Account management / Security / Data backup 등) 을 하고 나서야 순서가 돌아오기도 합니다. 

 

'데이터 마이그레이션' 도 그런 부류 중에 하나 입니다.

 

이런 것까지 신경써야하나 싶지만, 

결국 Data Lifecycle 내에 Data integrity 를 보장해야하는 기준에서는 

동일 수준에서 챙겨야 하는 게 맞다고 생각합니다. (아직 국내 inspection 에서 문제 삼지는 않겠지만요)

 

---

 

예전에 다른 제약사에 갔다가 이런 경험이 있었습니다. 

 

HPLC 데이터의 백업 및 관리를 위해서 기존 Stand-alone 시스템을 Server 와 연결시켜 DB 를 통합하고,

새로운 관리 solution 을 설치/Qualification 하셨다고 하더군요. 

 

그래서, 이전 안정성 시험 Data 를 보고 싶어 해당 데이터를 볼 수 있을지 여쭤봤는데,

이전 Data 들은 기존 PC desktop 에 있다고 하셨습니다. 해당 PC 는 보관 중이시더군요.

시간이 걸렸지만, 결국에는 해당 PC 본체 찾아서 Data 를 보긴 했습니다. 

 

더 여쭤보진 않았지만, 

아마도 해당 회사에는 데이터 Transfer 나 Migration 에 대한 정책/절차는 없었을 것 같습니다.

 

---

위 사례에서 기존 Data 의 사용 여부나 보존/Transfer 여부는 

이전 DB 시스템 도입을 위한 변경관리에서 capture 되었어야 할 것 같은데요.

 

신규 HPLC DB 에 기존 DB 를 옮길지, 기존 PC 를 보관할지를 DI Risk 기준에 따라 QRM 을 했다면,

Transfer/Migration 에 대한 SOP 가 없음을 인지할 수 있고, 동일 제조사의 S/W 였다면 PC 를 보관하는 결정 보다는 

기존 Data 를 신규 시스템에 Transfer 하는 결정을 했을 수도 있습니다. 

 

이때, S/W 버전이 달라지면 기존 버전의 Data 가 그대로 인식되지 않을 수 있습니다.

이 때 최신 버전의 S/W 가 인식할 수 있도록 형태를 변경하거나

형식을 변경해 전송하는 과정을 Migration 이라고 이해하면 될 것 같습니다. 

 

Migration 과 Transfer 는 비슷한 의미를 갖지만, 

Transfer 가 좀 더 넓은 범주라고 이해되고,

데이터의 전송 과정에서 호환성에 따른 변경 과정이 요구되면 Migration 됩니다. 

 

Migration 도 당연히 기능 검증이 사전에 요구되며,

기능 검증이 완료된 시스템이라고 할지라도,

Migration 이 필요한 Data 의 규모가 몇 년치 Data 를 포함할 정도로 크고 중요한 데이터가 포함되었다면,

Migration 작업에 대한 계획서를 통해 Migration 이 정확하고 누락없이 완료되었음을 평가하는 문서를 통해

Migration 의 무결성을 보증할 수 있습니다. (ERP or 전사 handling 되는 시스템 규모의 data)

(실제로 Migration 이 Fail 나는 경우도 있습니다)

---

DI 를 오래하면, 오만가지 의심병이 생깁니다.

 

from freepik