We're migrating a large user site using CBSubs from J1.5 to 2.5. The process to do this in general is not particularly an issue. In this instance the vehicle with be SPUpgrade which is much more reliable than JUpgrade. Versions of CB/CBSubs on both sites will be the latest.

My concern is related to CBsubs and Payal (or for that matter any payment gateway).

At one point I will have two sites coexisting (i.e. live and migration) with identical user data, CB Subs enabled, etc.. I know the license is floating and the licensing part is not an issue. The migration site will be installed as a subdomain/subfolder installation.

I intend to manually replicate all the CB and CBSubs tables across to the new site. There will inevitably be some significant testing of the site in general, which may take hrs or even 1-2 days. All other components of the site will have been tested prior to installing CBsubs and migrating user data, so testing is related specifically to CB/CBSubs.

What advice/steps do you propose to prevent the following (on the basis that the live site downtime is minimised and will therefore be live):

1) Any payment/email Events being triggered from the migration website, and/or Paypal particularly in relation to membership renewal anniversaries being reached (in this case quite a few DAILY).
2) Are there any CBsubs events triggered automatically (i.e. from the Joomla site end), which could therefore also emanate automatically from the migration site, confusing both the members (e.g. members receiving renewal emails from two installations) and also Paypal/IPN integration/double invoicing?

Alternately, to rephrase, what should be done on the migration site, once CB and CBSub are installed and fully populated with live data prior to testing which would prevent them from triggering or enacting LIVE events, such as email notifications, payment triggers, etc.. Is there a documented procedure for this? Any additional advise gratefully received.

At the end of the day the intention is to take the live site offline, re-migrate all CB and CBsubs data (to pick up all changes occurring since the testing phase), make new migration site live, then run some quick re-tests again before enabling new site to public online. this should result in a very short downtime for the live site. Obviously there will be backups backups more backups.