An Experimental Protocol for Explainable AI-Driven Secure Cloud Data Migration Using Synthetic Healthcare Data

Summary

This method presents a comprehensive explainable artificial intelligence (XAI) based framework to enable secure healthcare cloud data migration, leveraging a synthetic healthcare dataset within a controlled cloud environment. The result is a prototype that combines zero-trust security, time-based access control, and explainable anomaly detection to support migration transparency and security.

Abstract

In healthcare systems, more and more cloud data migration is being done, but this also changes the times when data transfer is probably the biggest risk in terms of security. This paper describes a reproducible protocol for explainable artificial intelligence (XAI)-based secure cloud data migration using a synthetic healthcare dataset and a controlled cloud environment. The developed framework merges zero-trust architecture, temporal least privilege, encrypted communication, centralized monitoring, and explainable anomaly detection to have a more secure, transparent, and auditable migration. The tests use a 10 GB dataset of synthetic electronic health records, comprising approximately 20 million records across 28 relational tables. The migration process was carried out on Amazon web services (AWS) using PostgreSQL databases and private virtual networks. For anomaly detection, Isolation Forest was utilized, and Shapley additive explanations (SHAP) served for the secure event interpretation. The framework was evaluated on ten separate migration attempts using metrics such as credential exposure duration, incident detection time, anomaly-detection accuracy, migration latency, and data integrity. Under the configuration tested, credential exposure was reduced from 24 h to 1 h (a 95.8% reduction), the accuracy of anomaly detection was 97.4%, incident detection time was reduced to about 15 min, and 100% data integrity was preserved through checksum validation. However, the stronger security measures resulted in an average migration latency increase of 11%. These results showcase the promise of merging explainable AI with secure cloud migration workflows for managing healthcare data.

Introduction

Cloud computing is now an integral part of healthcare systems worldwide, offering scalable storage, computational resources, and the ability to exchange health records, support decision-making systems, and enable health analytics through the cloud^1,2,3. With many healthcare institutions upgrading their information systems, moving to the cloud has become a vital step for them in order to transfer their sensitive health data held in the older on-premises systems to the cloud⁴. Proper migration leads to easier data retrieval, running operations in a more efficient manner, and supporting analytics with higher levels of intelligence, but at the same time, one cannot ignore quite serious security and privacy risks that getting data from one place to another entails⁵.

The migration phase is a notoriously vulnerable moment in the data lifecycle since healthcare data is being actively moved across systems and networks by the nature of the process⁶. Besides, organizations may get exposed to threats such as hacking of credentials, unauthorized access, intercepting data, manipulating schemes, and even data loss during the migration phase^6,7. Healthcare environments are less immune to such risks as patient information is highly sensitive and hence requires the highest level of compliance with regulatory and security measures^8,9. Short of that, it is not feasible to ensure data confidentiality, integrity, and accountability if the migration workflow is not secured and made observable^10,11.

A number of security frameworks and standards have been developed trying to make cloud security better. For instance, The National Institute of Standards and Technology (NIST) Zero Trust Architecture is all about making users, devices, and services be verified all the time¹², whereas cloud adoption frameworks give directions on governance, identity management, encryption, and monitoring¹³. In fact, present day cloud security methods focus on automation, infrastructure-as-code, and continuous monitoring^14,15. While such approaches are based on valuable security principles, to a large extent, they deal with general cloud deployment and operational environments rather than the migration process itself¹⁶. Actually, they hardly show step-by-step, detailed, and reproducible procedures for performing secure healthcare cloud data migration workflows that combine identity management, secure data transfer, validation, monitoring, and post-migration hardening¹⁷.

Machine learning anomaly detection has been recognized as a helpful technology in security monitoring of cloud environments. It detects abnormal system activity as well as potential security incidents¹⁸. Still, many anomaly detection methods are closed systems that fail to provide explanations on the rationale behind the flagging of a security event¹⁹. The inability to explain decision made by the system reduces credibility of administrators, makes auditing difficult and diminishes the value of automated security decisions in highly regulated healthcare environments²⁰. Explainable artificial intelligence (XAI) methods like SHapley Additive exPlanations (SHAP) and Local Interpretable Model-agnostic Explanations (LIME) not only provide clear explanations for machine learning predictions but also enhance understanding, accountability, and confidence in security monitoring systems^21,22.

Even though cloud security and explainable AI have made great strides, there is still a scarcity of reproducible experimental protocols combining secure migration controls with explainable security monitoring for the sake of integration²³. Existing research mostly addresses single components only, such as encryption, access control, anomaly detection, or cloud governance, and nowhere do they offer an integrated methodology that can be systematically implemented, evaluated, and reproduced²⁴. On top of that, hardly any studies have tried to bring together zero-trust security principles, temporal least privilege, centralized observability, and explainable anomaly detection into one single healthcare cloud migration workflow^25,26.

This paper introduces an Explainable AI-based framework for secure cloud data migration in healthcare systems to fill this void. The proposed architecture utilizes a zero-trust model, time-restricted access, secure communication, central logging and monitoring, and SHAP-based interpretable anomaly detection in a well-ordered migration process^27,28. The protocol is a step-by-step guide for implementing, monitoring, and assessing secure healthcare data migration under experimental conditions. By joining together security controls with AI interpretable monitoring, the framework being proposed intends to raise the level of transparency, auditability, and security all along the migration lifecycle^29,30.

Protocol

This study used a fully synthetic healthcare dataset generated for experimental evaluation of secure cloud data migration. No real patient data, protected health information (PHI), or identifiable healthcare records were used. Therefore, Institutional Review Board approval and informed consent were not required. All the materials used in this study are included in the Table of Materials.

1. Overview

1. Configure a secure cloud migration environment consisting of a source layer, migration hub layer, target layer, network layer, identity and access management layer, observability layer, and explainable AI layer.
2. Deploy all components within isolated cloud environments to support secure healthcare data migration. Establish encrypted communication channels between all system components.
3. Execute the protocol through dataset preparation, environment configuration, architecture deployment, secure migration, anomaly monitoring, and post-migration validation. The overall architecture of the proposed Explainable AI-driven secure cloud data migration framework is illustrated in Figure 1.

Figure 1: Overall architecture of the explainable artificial intelligence (XAI)-enabled secure cloud data migration framework for healthcare systems. The framework consists of the identity and access management layer, source database layer, migration hub layer, target cloud database layer, network security layer, observability layer, explainable AI monitoring layer, and cross-cutting security and governance services. The architecture integrates temporal least-privilege access control, TLS 1.3 encrypted communication, checksum-based integrity verification, continuous security monitoring, and SHAP-based explainability to provide secure, transparent, and reproducible healthcare database migration. This figure was created by the authors using Microsoft PowerPoint (Microsoft 365). Please click here to view a larger version of this figure.

2. Computational environment configuration

1. Configure the computational environment
   1. Prepare the computational resources required for secure cloud data migration and explainable AI-based monitoring.
   2. Install and configure all hardware, software, cloud services, databases, security tools, and machine learning libraries listed in the Table of Materials. Verify that all required components are operational before initiating the migration experiment.
2. Configure the Cloud Environment
   1. Set up a cloud environment that is secure for healthcare data migration. Set up a private VPC for seamless communication between the source, migration hub, and target systems. Use strong encryption not only when data is stored, but also when it is transmitted.
   2. Prepare the target database and migration services according to the details mentioned in the Table of Materials.
3. Configure identity and access management. configure monitoring and logging services.

3. Dataset preparation and description

1. Generate a synthetic healthcare dataset using the Faker Python library listed in the Table of Materials. Configure demographic attributes, including patient age, sex, ethnicity, and geographic location, using predefined probability distributions.
2. Generate clinical information, including diagnoses, laboratory results, medications, allergies, procedures, and hospital admissions, while preserving realistic clinical relationships.
3. Generate longitudinal patient encounters by assigning multiple visits to individual patients according to predefined visit-frequency distributions.
4. Generate timestamps for admissions, laboratory investigations, medication administration, discharge summaries, and audit logs using chronological event ordering.
5. Introduce clinically realistic missing values, duplicate records, and outlier observations according to predefined data-quality distributions.
6. Replace all personally identifiable information with synthetic values generated using the Faker library. Validate referential integrity and logical consistency before exporting the dataset. Export the validated dataset in PostgreSQL-compatible SQL format. Configure the dataset to support realistic healthcare migration scenarios. The characteristics of the generated dataset are summarized in Table 1.
7. Define database relationships. Assign Patient_ID as the primary key for the patient table. Establish foreign-key relationships between patient, visit, laboratory, medication, and audit-log tables. Verify referential integrity across all tables before initiating migration.
8. Simulate realistic healthcare data characteristics. Generate patient ages using a normal distribution. Generate visit frequencies using a Poisson distribution. Introduce missing values at a rate of 5% to simulate real-world EHR incompleteness. Replace all patient identifiers with hashed values before migration. Verify that all generated records conform to predefined schema constraints.
9. Validate the generated dataset by checking schema consistency, referential integrity, missing values, duplicate records, and predefined quality constraints before migration.

Parameter	Value
Dataset Type	Synthetic Healthcare EHR Dataset
Dataset Size	10 GB
Total Records	20 Million
Number of Tables	5 Core Tables- 28 relational tables
Patient Records	5,000,000
Visit Records	10,000,000
Laboratory Results	4,000,000
Medication Records	3,000,000
Audit Logs	5,000,000
Primary Key	Patient_ID
Missing Value Rate	5%
Age Distribution	Normal Distribution
Visit Frequency	Poisson Distribution
Integrity Threshold	<0.1% Violations

Table 1:  Characteristics of the synthetic healthcare dataset used for protocol validation. The table provides an overview of the dataset, such as database size, number of relational tables, total records, patient attributes, clinical variables, and validation characteristics to reproduce the secure migration experiments.

4. System architecture deployment

1. Deploy the secure cloud migration architecture consisting of the source layer, migration hub layer, target layer, network security layer, observability layer, and explainable AI layer. The deployed system architecture used in this study is illustrated in Figure 2.
2. The framework is composed of six working layers, which, during the migration process, carry out their functions one after another. The first layer, the Source Layer, is the one that contains the synthetic healthcare database. 
3. The Migration Hub is the one in charge of schema extraction, encrypted data transfer, integrity validation, and migration orchestration. The target layer is where the migrated database is stored in Amazon RDS PostgreSQL. 
4. The network security layer is the one that safeguards all the communications by the use of private VPC endpoints, TLS 1.3 encryption, security groups, and network access control lists. 
5. The observability layer is the one that is always collecting authentication logs, migration logs, database activity logs, and security events with the help of Amazon CloudWatch.
6. The explainable AI layer is the one that gets the security telemetry that has been collected, runs it through an Isolation Forest algorithm, and produces SHAP-based explanations for the anomalies that have been found. All architectural layers communicate with one another via private network channels that are authenticated during the entire migration workflow.
7. Deploy and verify the source database environment to ensure secure access and data availability before migration.
   1. Set up a PostgreSQL 16 database with the synthetic healthcare dataset. Keep patient information, visit details, lab results, drug records, and audit logs in the source database.
   2. Restrict database access to authorized migration services and administrative users only. Verify database availability and connectivity before initiating migration operations.
8. Configure the migration hub to coordinate schema extraction, encrypted data transfer, and migration orchestration.
   1. Deploy a dedicated migration server within the private Virtual Private Cloud (VPC). Configure migration orchestration services to coordinate schema extraction, data transfer, and validation activities.
   2. Enable schema-validation services to verify compatibility between source and target environments. Enable integrity-verification services to validate migrated data during and after transfer. Verify communication between the migration hub and database systems before executing migration tasks.
9. Deploy the Target Layer. Deploy Amazon RDS PostgreSQL 16 as the target database environment. Enable automatic backup and recovery services. Enable AES-256 encryption for data stored within the target database.
10. Configure Network Security. Disable all public IP addresses associated with migration resources. Permit communication only through private endpoints within the VPC. Configure network access control lists (NACLs) and security groups. Enable TLS 1.3 encryption for all communications between system components. Verify that no publicly accessible endpoints remain active.
11. Configure centralized monitoring to continuously collect security events, migration logs, and system performance metrics.
    1. Enable Amazon CloudWatch logging and monitoring services. Collect authentication logs, migration logs, database activity logs, and security-event logs. Configure log retention for 365 days. Enable immutable log storage to support auditing and compliance requirements. Verify real-time metric collection and alert generation.
12. Configure the explainable AI environment to perform real-time anomaly detection and generate interpretable security explanations.
    1. Deploy anomaly-detection services within the monitoring environment. Configure the Explainable AI framework to process security telemetry generated during migration. Connect security telemetry streams from the source, the migration hub, the target database, and the monitoring services.
    2. Enable real-time anomaly detection and SHAP-based explanation generation. Verify successful ingestion of telemetry data before initiating migration experiments.

Figure 2: Deployment architecture of the secure healthcare cloud migration framework. The deployment environment illustrates the source PostgreSQL database containing the synthetic healthcare dataset, the dedicated migration hub within a private virtual private cloud (VPC), the Amazon RDS PostgreSQL target database, the network security layer, centralized observability through Amazon CloudWatch, and the Explainable Artificial Intelligence monitoring layer. All communication occurs through private endpoints protected by TLS 1.3 encryption. This figure was created by the authors using Microsoft PowerPoint (Microsoft 365). Please click here to view a larger version of this figure.

5. Secure migration workflow

NOTE: Execute the secure migration workflow by performing threat modeling, schema transfer, secure data migration, migration validation, and post-migration hardening. 

1. Identify potential security threats and map appropriate mitigation controls before initiating the migration process.
   1. Identify migration assets, potential attack vectors, and realistic cyberattack scenarios.  
   2. Evaluate credential theft resulting from compromised authentication tokens, insider attacks involving unauthorized administrative access, replay attacks targeting previously intercepted authentication requests, man-in-the-middle (MITM) attacks attempting to intercept encrypted communication channels, schema tampering intended to modify database structures during migration, and privilege-escalation attacks aimed at obtaining unauthorized administrative permissions.
   3. Check that using temporal least-privilege credential management is sufficient in preventing credential theft and privilege-escalation attacks. Verify that communication encrypted with TLS 1.3 protects from replay attacks and man-in-the-middle attacks.
   4. Verify identity and access management (IAM) policies prevent unauthorized administrative access. Verify continuous audit logging keeps a record of all security-related migration activities. Make sure that checking by SHA-256 checksum is able to detect unauthorized changes to schema or data.
   5. Verify that the explainable anomaly detection framework can locate unusual migration activities and can also provide interpretable security explanations. Make a security control map for each threat that has been identified. Verify that all identified threats are adequately mitigated before you start migrating the database. The authors summarized the threat model and security controls in Table 2.
2. Transfer Database Schema. Extract schema definitions from the source PostgreSQL database. Validate schema compatibility with the target database environment. Verify table structures, primary keys, foreign keys, indexes, and constraints. Deploy validated schema definitions to the target database. Confirm successful schema deployment before transferring data.
3. Migrate healthcare data securely through encrypted communication channels while continuously monitoring migration activities.
   1. Configure the migration batch size to 10,000 records per transaction. Establish encrypted communication channels using TLS 1.3. Transfer data through private network endpoints within the virtual private cloud (VPC).
   2. Enable automatic retry attempts with a maximum of three retries for failed transactions.
      ​Maintain data-transfer throughput between 100 MB/s and 150 MB/s. Monitor migration activities continuously throughout the transfer process. Record all migration events in centralized audit logs.
4. Verify migration completeness and integrity by comparing checksums, record counts, and database structures.
   1. Generate SHA-256 hash values for all source tables before the migration, and SHA-256 hash values for all target tables after the migration. Match source and target checksum values. Cross-check row counts for source and target databases. Check consistency of schemas, table relationships, and database constraints. Consider migration as successful only when checksum values, record counts, and schema structures are identical.
5. Remove temporary privileges and finalize security controls after successful completion of data migration.
   1. Revoke all temporary migration credentials immediately after migration completion. Remove elevated migration privileges from service accounts. Archive audit logs and security monitoring records.
   2. Verify successful completion of backup procedures. Decommission temporary migration servers and supporting resources. Perform a final security review of the migrated environment. Document migration outcomes and validation results. The complete secure migration workflow used in this study is illustrated in Figure 3.

Threat Scenario	Security Control	Detection Method	Mitigation
Credential theft	Temporal Least Privilege (TLP)	IAM logs	Automatic credential revocation
Insider attack	Role-Based Access Control (RBAC)	Audit logs + SHAP	Session termination
Replay attack	TLS 1.3 + Nonce validation	Network monitoring	Reject duplicated requests
Man-in-the-Middle (MITM)	TLS 1.3 encryption	Certificate validation	Encrypted communication
Schema tampering	SHA-256 checksum + schema validation	Integrity verification	Restore validated schema
Privilege escalation	IAM policy enforcement	Security logs	Privilege revocation

Table 2:  Threat model and respective security measures taken in the migration framework proposed. The table outlines the main representative security threats and their corresponding mitigation mechanisms based on zero-trust security principles, encryption, identity management, integrity verification, monitoring, and explainable anomaly detection.

Figure 3: Workflow of the proposed secure cloud database migration protocol. The protocol consists of seven sequential stages: threat modeling, schema transfer, secure database migration, migrated data validation, post-migration hardening, audit logging and archival, and migration completion. Security monitoring, encrypted communication, identity management, immutable logging, and explainable anomaly detection are maintained throughout the migration workflow. This figure was created by the authors using Microsoft PowerPoint (Microsoft 365). Please click here to view a larger version of this figure.

6. Configure explainable AI monitoring

NOTE: The outline of the process is: identifying migration security characteristics, building a model to detect irregularities, recognizing when migration actions are suspicious, and producing explainable results through SHAP interpretation methods.

1. Extract and preprocess security telemetry features required for anomaly detection and explainability analysis.
   1. Collect security logs from database servers, authentication servers, application servers, and network monitoring systems. Aggregate all migration-related events into a centralized log repository. Remove duplicate records and incomplete entries. Synchronize timestamps across all log sources using coordinated universal time (UTC).
   2. Calculate access frequency for each user during migration operations. Record the number of failed login attempts associated with each account. Monitor changes in source IP addresses throughout migration sessions.
   3. Measure user session duration from login initiation to termination. Calculate inbound and outbound data transfer volumes during migration activities. Normalize all extracted features using Min-Max normalization.
   4. Table 3 summarizes the security features used for anomaly detection and explainability analysis.
2. Train and validate the Isolation Forest model using the prepared security feature dataset.
   1. Partition the dataset. Randomly divide the dataset into Training set (70%), Validation set (15%), and Testing set (15%). Maintain a consistent distribution of normal and anomalous events across all subsets.
   2. Explainable AI Model Selection. Select the Isolation Forest algorithm because it efficiently detects anomalous migration activities without requiring labeled training data. Use the algorithm to isolate abnormal observations through recursive random partitioning of the feature space. 
   3. Apply SHAP TreeExplainer to quantify the contribution of each security feature to the anomaly prediction and improve transparency of the security monitoring process.
   4. Configure the anomaly detection model. Initialize an Isolation Forest model. Configure the model using the parameters listed in Table 4.
   5. Define the mathematical formulation used to calculate anomaly scores and explain feature contributions.
      1. Define the security feature vector for each migration event as shown in Equation 1.
         x_i = [x₁ , x₂, x₃, x₄, x₅ ] (1)
         where x₁ denotes access frequency, x₂ denotes failed login count, x₃ denotes IP address change frequency, x₄ denotes session duration, and x₅ denotes data transfer volume.
      2. Extract the security features from migration logs. Normalize all feature values before model training. Calculate the Isolation Forest anomaly score for each migration event using Equation 2.
             (2)
         where S(X,n) denotes anomaly score of observation X, X denotes security feature vector, E(h(X)) is expected path length of observation X, c(n) is average path length of unsuccessful searches in a binary search tree, and n is the total number of training samples. The normalization factor is calculated as shown in Equation 3.
            (3)
         where H(n-1) denotes  the (n-1)th harmonic number. 
      3. Classify migration events with anomaly scores greater than the predefined decision threshold as anomalous.
      4. Apply SHAP (SHapley Additive exPlanations) to explain the contribution of each security feature to the anomaly prediction. Calculate the SHAP value for feature i using Equation 4.
            (4)
         where (F) denotes the complete feature set, (S) denotes a subset of features, and (f(.)) denotes the Isolation Forest prediction function.
      5. Calculate the global feature importance by computing the mean absolute SHAP value using Equation 5.
             (5)
         ​where (N) denotes the total number of migration events.
      6. Rank the security features according to their mean absolute SHAP values. Generate SHAP summary plots, dependence plots, and force plots to visualize global and local feature importance.
   6. Train the Isolation Forest model using the training dataset. Evaluate model performance using the validation dataset. If it is necessary, change the contamination thresholds. Store the model configuration that performs the best. Validate model performance. Determine metrics like accuracy, precision, recall, F1-score, and ROC-AUC. Note down the model performance measures for later comparison.
3. Apply the trained model to identify abnormal migration events and classify suspicious activities.
   1. Perform anomaly prediction. Apply the trained Isolation Forest model to the testing dataset. Generate anomaly scores for all migration events.
   2. Identify suspicious activities. Determine if migration events are typical or anomalous. Mark as suspicious those events that surpass predetermined anomaly levels. Produce anomaly documentation for security scrutiny.
   3. Completion of the anomaly detection process yields anomaly scores, labels migration events as normal or anomalous, measures detection effectiveness through ROC analysis, and spots key security anomalies. Samples of outputs produced by the designed process are shown in Figure 4.
   4. Categorize detected anomalies. Classify anomalies into authentication anomalies, network anomalies, session anomalies, and data-transfer anomalies. Keep the anomaly labels for the explanation analysis.
   5. Evaluate detection performance. Check the recorded security incidents to date. Then, using them as a reference, evaluate the anomalies that have been detected and figure out which of the two were true anomalies. Determine the rate at which anomalies are detected and the rate of false positives. Make an official record of the documentation of detection accuracy to be able to reproduce it.
4. Generate SHAP-based explanations to interpret the contribution of individual security features to anomaly predictions.
   1. Configure the SHAP environment. Load the trained Isolation Forest model. Initialize SHAP TreeExplainer. Verify successful integration between the anomaly detection model and the explainability framework.
   2. Select background samples. Randomly select 1,000 representative samples from the training dataset. Use the selected samples as the SHAP background dataset. Calculate SHAP values. Compute SHAP values for all detected anomalies. Measure individual feature contributions to anomaly predictions. Store SHAP outputs for further analysis.
   3. Generate global explanations. Create SHAP summary plots showing overall feature importance. Generate SHAP bar charts based on mean absolute SHAP values. Produce SHAP dependence plots for highly influential features.
   4. Generate local explanations. Select representative anomalous migration events. Create SHAP force plots and waterfall plots. Visualize feature contributions responsible for each anomaly.
   5. Representative explainability outputs generated during the interpretation process are shown in Figure 5. These visualizations demonstrate global feature importance, feature contribution rankings, dependence relationships between influential security features, and local explanations for individual migration anomalies.
   6. Rank security features. Calculate mean absolute SHAP values for all features. Rank features according to their contribution to anomaly detection. Identify the most influential security indicators affecting migration security. Table 5 summarizes the SHAP-based feature importance rankings.
   7. Validate explanation consistency. Repeat SHAP analysis across five independent experimental runs. Measure explanation stability and consistency. Verify that feature rankings remain stable across repeated analyses.
      NOTE: Table 6 provides common issues encountered during explainable anomaly detection and recommended corrective actions.

Feature	Description	Purpose
Access Frequency	Number of user access requests during migration	Detect abnormal access behavior
Failed Login Count	Number of unsuccessful authentication attempts	Identify brute-force or unauthorized access attempts
IP Address Changes	Frequency of source IP address changes	Detect suspicious network behavior
Session Duration	Length of user sessions during migration	Identify abnormal session activities
Data Transfer Volume	Amount of data transferred during migration	Detect unusual data movement or exfiltration

Table 3:  Security telemetry features used for explainable anomaly detection. The table presents the security features that were monitored during the database migration, their meanings, the ways in which they were measured, and how they helped with anomaly detection and explainability analysis.

Parameter	Value	Description
Algorithm	Isolation Forest	Anomaly detection model
n_estimators	100	Number of isolation trees
contamination	0.02	Expected anomaly proportion
max_samples	Auto	Samples used per tree
random_state	42	Reproducibility seed
bootstrap	False	Sampling without replacement
Training Set	70%	Model training data
Validation Set	15%	Hyperparameter validation
Testing Set	15%	Final model evaluation

Table 4: Configuration of Isolation Forest used for detecting anomalies during secure database migration. This table details the hyperparameter setups of the Isolation Forest model for training, such as how the dataset was split, the level of contamination, the number of estimators, the random seed, and the evaluation setup.

Figure 4: Representative outputs of the anomaly detection framework during secure cloud data migration. (A) Distribution of Isolation Forest anomaly scores showing the anomaly threshold. (B) Classification of migration events into normal and anomalous categories. (C) Receiver operating characteristic (ROC) curve demonstrating the performance of the Isolation Forest model (AUC = 0.97 ± 0.01). (D) Representative anomalous migration events showing anomaly scores, predicted labels, influential security features, and anomaly categories. This figure was generated by the authors using Python 3.11 (Matplotlib 3.9) and formatted using Microsoft PowerPoint (Microsoft 365). Please click here to view a larger version of this figure.

Figure 5: Examples of SHAP-based explainability outputs produced during anomaly interpretation. (A) SHAP summary plot highlighting the most important features globally. (B) Ranking of security features based on their mean absolute SHAP value. (C) SHAP dependence plots demonstrating how the number of failed logins and the volume of data transfer affect the anomaly prediction. (D) SHAP force plot offering a local explanation for a typical abnormal migration event. These charts showcase the global and local interpretability of the proposed anomaly detection model. This figure was generated by the authors using Python 3.11 (Matplotlib 3.9) and formatted using Microsoft PowerPoint (Microsoft 365). Please click here to view a larger version of this figure.

Rank	Feature	Mean Absolute SHAP Value	Interpretation
1	Failed Login Count	0.352	Most influential indicator of anomalous activity
2	Data Transfer Volume	0.287	Strong contributor to anomaly detection
3	IP Address Changes	0.221	Indicates suspicious network behavior
4	Session Duration	0.184	Associated with abnormal user sessions
5	Access Frequency	0.156	Reflects unusual access patterns

Table 5:  SHAP feature importance scores of security telemetry data. The table shows security feature ranking according to their mean absolute SHAP values and outline their respective contributions to the prediction of anomalies.

Issue	Possible Cause	Recommended Solution
Few anomalies detected	Contamination parameter too low	Increase the contamination threshold and retrain the model.
High false-positive rate	Noisy or inconsistent migration logs	Clean log data and normalize security features before model training.
Unstable SHAP explanations	Insufficient background samples	Increase the number of representative background samples used by SHAP.
Poor anomaly detection accuracy	Feature imbalance or inadequate preprocessing	Apply feature normalization, balancing, and quality-control procedures.
Slow model convergence	Large dataset or limited computational resources	Optimize hyperparameters or use GPU/parallel processing.
Communication failures	Network instability during monitoring	Verify secure communication channels and repeat synchronization.
Missing security features	Incomplete log collection	Validate log sources before feature extraction and regenerate the feature dataset.

Table 6: Guide for troubleshooting Explainable Artificial Intelligence-based secure database migration. This table provides a summary of typical implementation problems, possible reasons, diagnostic signs, recommended actions, and outcomes expected as a result of protocol execution and reproducibility.

7. Performance evaluation

NOTE: This section describes the experimental procedure used to compare the baseline migration framework with the proposed zero-trust explainable AI-based migration framework. Performance evaluation includes security, anomaly detection capability, migration efficiency, and statistical validation under identical experimental conditions.

1. Configure both the baseline and proposed environments under identical conditions to enable a fair performance comparison.
   1. Configure the conventional migration environment. Configure long-term static credentials with a validity period greater than 24 h. Enable public network endpoints for database access. Disable AI-based anomaly detection and explainability mechanisms. Monitor migration activities manually using conventional security logs. Record migration events for subsequent performance comparison.
   2. Configure the Zero-Trust migration framework. Enable temporal least-privilege credentials with automatic expiration after migration completion. Disable all public network endpoints. Enable private network communication using secure channels.
   3. Deploy the trained Isolation Forest anomaly detection model. Enable SHAP TreeExplainer for model interpretation. Configure automated security monitoring throughout the migration process. Verify secure communication between all migration components before execution.
2. Perform repeated migration experiments under controlled conditions to evaluate framework reproducibility.
   1. Perform migration experiment. Conduct ten independent migration experiments for both the baseline and proposed environments. Maintain identical hardware, software, and network configurations throughout all experiments.
   2. Migrate 10 GB of healthcare data during each experimental run. Repeat all experiments under identical workload conditions. Record security events, migration logs, anomaly detection outputs, and execution times during every experiment.
   3. Validate migration integrity. Calculate SHA-256 checksums before and after migration. Verify complete data integrity after every migration experiment. Document checksum validation results.
3. Calculate quantitative security, migration, and anomaly detection metrics for comparative evaluation.
   1. Measure security performance. Measure credential exposure duration. Calculate the number of exposed credentials during migration. Measure incident detection time. Record public network exposure duration.
   2. Evaluate anomaly detection performance. Calculate anomaly detection accuracy,  precision, recall, F1-score, and area under the receiver operating characteristic curve (AUC). Evaluate migration performance. Measure total migration latency and calculate migration throughput. Record communication overhead introduced by security mechanisms.
   3. Perform statistical validation. Calculate the mean and standard deviation for all performance metrics. Compute 95% confidence intervals. Perform paired Student's t-tests to compare the baseline and proposed frameworks. Consider statistical significance at p < 0.05. Representative performance evaluation results generated during the experimental comparison are shown in Figure 6.
   4. Table 7 summarizes the quantitative performance comparison between the baseline and the proposed migration framework.
      Table 8 summarizes common implementation issues encountered during secure database migration, their possible causes, and recommended corrective actions.

Figure 6: Performance comparison between the baseline migration framework and the proposed zero-trust, explainable AI-enabled secure cloud migration framework. (A) Comparison of credential exposure duration using long-term and temporal least-privilege credentials. (B) Comparison of anomaly detection performance metrics, including accuracy, precision, recall, F1-score, and AUC. (C) Comparison of migration latency across ten independent experimental runs, showing that the latency increase remained below the predefined acceptance threshold. (D) Statistical comparison of key performance metrics using paired Student's t-tests, showing mean differences and 95% confidence intervals. Error bars represent 95% confidence intervals from ten independent experimental runs. This figure was generated by the authors using Python 3.11 (Matplotlib 3.9) and formatted using Microsoft PowerPoint (Microsoft 365). Please click here to view a larger version of this figure.

Performance Metric	Baseline Framework (Mean ± SD)	Proposed Framework (Mean ± SD)	Improvement	95% Confidence Interval	p-value
Credential Exposure Duration (h)	24.70 ± 1.32	0.42 ± 0.18	98.3% reduction	23.6–24.9	<0.001
Anomaly Detection Accuracy (%)	72.4 ± 2.1	94.6 ± 1.3	+22.2%	20.8–23.5	<0.001
Precision (%)	68.1 ± 2.5	92.7 ± 1.5	+24.6%	23.1–26.0	<0.001
Recall (%)	70.3 ± 2.4	93.1 ± 1.6	+22.8%	21.4–24.2	<0.001
F1-score (%)	69.2 ± 2.2	92.9 ± 1.4	+23.7%	22.3–25.0	<0.001
AUC	0.78 ± 0.03	0.97 ± 0.01	+0.19	0.17–0.21	<0.001
Migration Latency (min)	87.6 ± 3.2	97.4 ± 2.9	11.2% overhead	8.9–10.7	0.002
Data Integrity (%)	99.8	100.0	0.2% improvement	0.1–0.3	0.031
Public Network Exposure	Enabled	Eliminated	100% eliminated	N/A	<0.001

Table 7: Baseline and proposed secure database migration frameworks: A performance comparison. The table displays credential exposure duration, anomaly detection effectiveness, migration latency, data integrity, and security enhancements assessed quantitatively during the protocol validation.

Issue	Possible Cause	Recommended Solution
Migration authentication failure	Expired or invalid temporary credentials	Regenerate temporal credentials and verify IAM policies before restarting migration.
High migration latency	Network congestion or insufficient bandwidth	Optimize network routing, schedule migration during low-traffic periods, and verify endpoint connectivity.
False-positive anomaly alerts	Improper Isolation Forest contamination threshold	Tune contamination parameter using the validation dataset and retrain the model.
Unstable SHAP explanations	Insufficient or non-representative background samples	Increase the SHAP background sample size and ensure representative sampling.
Data integrity mismatch	Interrupted migration or corrupted data transfer	Re-run migration after validating SHA-256 checksum values and source/target consistency.
Secure endpoint connection failure	Firewall or TLS configuration errors	Verify SSL/TLS certificates, firewall rules, and private endpoint configuration.
Low anomaly detection accuracy	Incomplete feature extraction or poor preprocessing	Review feature engineering, normalize security features, and retrain the model.
Model convergence issues	Inappropriate hyperparameters	Adjust learning parameters and validate model performance before deployment.

Table 8: Troubleshooting guide for secure healthcare database migration. The table lists frequent migration errors, their possible roots, corrective measures advised, and expected results to ensure a reliable execution of the secure migration protocol.

Results

Experimental overview

The proposed explainable artificial intelligence (XAI)-enabled secure cloud data migration protocol was evaluated using a synthetic healthcare dataset comprising approximately 20 million electronic health record (EHR) records distributed across 28 relational database tables, totaling 10 GB. The experiments were conducted in an Amazon Web Services (AWS) cloud environment using Amazon RDS PostgreSQL 16, private Virtual Private Cloud (VPC) networking, TLS 1....

Discussion

In this research, a reproducible, secure cloud database migration protocol was developed that incorporates zero-trust security principles, time-based least-privilege access control, explainable artificial intelligence (XAI), and continuous security monitoring, all within a restricted experimental setup. Using a new migration algorithm was not the intention of this paper; therefore, the authors primarily present a standardized workflow that makes it possible for researchers and practitioners to perform, assess, and reprod...

Materials

List of materials used in this article

Name	Company	Catalog Number	Comments
AES Encryption	NIST	AES-256	Data-at-rest encryption
Amazon RDS PostgreSQL	Amazon Web Services	PostgreSQL 16	Target database
Cloud Platform	Amazon Web Services	AWS	Cloud infrastructure
CloudWatch	Amazon Web Services	Latest Stable Release	Monitoring and logging
Docker	Docker Inc.	27.0	Containerization
Faker	Faker Developers	30.0	Synthetic data generation
GPU	NVIDIA	RTX 4090	24 GB VRAM
Matplotlib	Matplotlib Developers	3.9	Visualization
NumPy	NumPy Developers	1.26	Numerical processing
Operating System	Canonical	Ubuntu 22.04 LTS	System environment
Pandas	PyData	2.2	Data processing
PostgreSQL	PostgreSQL Global Development Group	16	Source database
Python	Python Software Foundation	3.11	Programming language
Scikit-learn	Scikit-learn Developers	1.5	Machine learning
SHAP	SHAP Developers	0.46	Explainable AI
Terraform	HashiCorp	1.8	Infrastructure provisioning
TLS	IETF	TLS 1.3	Data-in-transit encryption
Virtual Private Cloud	Amazon Web Services	VPC	Private network environment
Workstation	Dell/HP	NA	Intel Xeon Gold 6226R, 64 GB RAM, 1 TB SSD