Migrate Oracle Database to Any Cloud (AWS,Azure,Google,IBM etc ) Using Native Tool - Datagaurd

Oracle Database Migration to Any Cloud (AWS,Azure etc )

 Pre-communication (No-Downtime)

• Ensure and agreed with plan & cutover window 
• Ensure all stakeholder should be on same page 
• Ensure everyone copid in mail and meetings
• Ensure all issue should be documented database & application wise during iteration/testing
• Dicussed and aggred who is from available during cutover winodw (application owner,database lead,infa lead etc)   

Pre-Migration Pahse (No-Downtime) 

On Source Database 

• Delete/Remove all backup tables /unused objects from database with help of application team 
• Do username & password backup  
• Get read only access to database server
• Ensure db_unique_name is the same as the db_name
• Set and crosscheck all parameter related to dataguard configuration 
• check remote connectivity is working fine and port should be open at firewall level 
• check and validate database corruption 
• prepare & test  shared mout point  (NFS/EFS/S3FS)  
• Take the database backup including archivelogs and standby control file to create standby database
• check and backup networkfiles (tnsnames.ora,listiner.ora)
• check if wallet is configured
• check if any encryption (TDE )is enables 

Prepare Target envirnoment (No-Downtime) 

• Install oracle binrary software & Build the target database server 
• Install Grid software if required 
• Install Oracle database binary 
• Configure & enable SSH & SCP (with help of root account - Infra team)
• Configure and validate all  mount points (database/aplication)
• Configure and validate same shared  mount points (NFS/EFS/S3FS) in the target server/s.
• Restore the database backup and configure standby database 
• Incase ASM add spfile to grid software using srvctl 
• Validate remote database connctivity  
• Setup dataguard replication  from primary (source) to standby (target) database 

Migration pahse (Downtime start)

• check and validate primary and standby database in sync and no GAP 
• Stop Application associated database 
• create test user/test tablespace and test table on primary database 
• Do 4-5 archive log switch on primary (source) database .
• Again check  and validate primary and standby database in sync and no GAP
• Check active database sessions in primary (source)  database. if still acitve after stopping the application ,  kill those users  
• Create a guaranteed flashback restore point - for this enough FRA space should be available 
• Multiple way to do 
• Using manual swithover 
• Using DGMGRL ( need to configure DGMGRL )
• Using manual Failover (No rollback in this case) 
• Validate the migated database
• Setup & validate connection with application  
• Configure & update on premise DNS with new IP address (target) and create load balancer rules (if using)
• Handover to application team for validation 

Post Migration phase (No-downtime) 

• Take golden database backup after successful migration 
• Configure & schedule  database jobs 
• Configure & setup database monitoring

Rollback Phase 

• Stop the application on target database 
• Rollback the database using restore point (source database)
• Update the DNS with old entry for rollback (if required)
• Start and validate the database 
• Connect with database & start the application