The Stran­gler Pat­tern for Database Mi­gra­tion (With XA Trans­ac­tions)

How XA can help you mi­grate data­bas­es...

The Prob­lem

So you are us­ing a DBMS from one ven­dor and want to mi­grate to a DBMS from an­oth­er ven­dor. You need some time to mi­grate all DBMS ac­cess code to the new data­base plat­form - so how do you do this with­out a big-bang re­lease af­ter X months (al­most a guar­an­tee for fail­ure)?

The So­lu­tion

If both DBMS sup­port XA then the so­lu­tion is rel­a­tive­ly easy:

• Set­up the ini­tial in­stance of the tar­get DBMS
• Change all DBMS up­dates to go to the two DBMS with XA trans­ac­tions (so up­dates are guar­an­teed to hap­pen on both in­stances dur­ing the mi­gra­tion)
• Grad­u­al­ly mi­grate your ap­pli­ca­tions to use only the tar­get DBMS
• When no ac­cess­es re­main to the orig­i­nal DBMS, take out the dual writes with XA trans­ac­tions

Lim­i­ta­tions

This works only if both DBMS sup­port XA. Why com­pli­cate your life by se­lect­ing a stor­age tech­nol­o­gy with­out XA sup­port? You will ef­fec­tive­ly lock your­self in be­cause you know you won't be able to mi­grate away eas­i­ly.