Going live

The two things I worry most about in an implementation are:
1. Payment Systems
2. Data

There are lots of other things that need to be done - branding the site, writing reports, setting up the database, etc. - but those are all
* More directly under our control
* Capable of temporary stop-gap solutions (if the site design isn't perfect, you can choose to go live with it slightly ugly and have it fixed the next day).

Payment systems are troublesome because some banks and payment gateways require long testing periods before they will activate an account, and there's almost no pressure that one can bring to bear on them that will speed things up at all. Starting the process of getting a Merchant ID from scratch can be slow, and getting the set up correct for Card Present, Mail Order / Telephone Order (MOTO), and eCommerce, all of which have different requirements, can be complicated .

Data is a worry because once you have some sales on the new system, you can't just switch it off and fall back to the old system if anything goes wrong. If the new system knows that seat A15 has been sold and the old one doesn't, and you don't want to do a reverse data conversion from the new system to the old one (which, trust me, you don't), then you're committed.

But there are effectively three states of data in the system. It's all the same data - who bought what - but some of it is "Sales for performances well in advance", where what's important about it is that you don't sell the same seat twice, some of it is "Sales that people are going to collect today", where what's important is that you need to be able to swipe a credit card and retrieve and print an order, and some of it is "Historical Sales", that you are going to use for marketing.

Doing a full overnight conversion means that the next days staff will come into the venue and
* Have to sell advance tickets off a new system - and trust that advance availability is correct
* Have to retrieve and print tickets that were sold on the old system, off the new system
* If anything goes slightly amiss, which it will, deal with customer service and refunds and cancellations on the new system
* Have to deal with all of this in a totally new user interface

which is a lot to deal with no matter how much training there has been, and if a data problem comes to light, say, in the evening whilst tickets are being collected, it's too late to redo the conversion, because the database has that day's sales in it.

Therefore, to mitigate all these risks, I'd prefer to run the two systems side by side, with a cut off date of N months ahread such that performances after that cut off date are in the new system, performances before that date are in the old system. I have seen on many occasions dataconversions that cause an ongoing series of bugs that are never fully resolved, but which eventually "go away" simply because all of the converted performances have happened; it would have been better not to have tried at all.

Running the systems side by side is more effort for staff, because they'll have to switch between systems whilst selling tickets. It's more effort for reporting, because sales will be recorded in two separate systems. It's more effort in the intim period for online sales, because we'll need to show two sets of content on the website.  But I think it gives a better result at a lower risk.


So.

First we pick a "cut over date". No more performance get put on sale in the old system that are after the cut over date.

And start talking to the bank about getting an internet merchant id, and talking to payment gateway providers. I will happily integrate with any payment provider, but so far the ones I've found friendliest to deal with are http://www.securetrading.com/

And we start the process of branding and skinning the software so that it fits in with the existing site.

Then we set up the new system with all the performances after the cutover date and test and make sure everything's happy. If this takes longer than expected, the cutover date can be slipped and more performances put on sale in the old system.

Once the internet payment solution is sorted, and the site skinning and branding done, we start selling performances that are after the cutover date on the new system. This should still be about 2 months distant, as you'll have needed to do advance sales on the old system. Therefore, there's plenty of time to sort out any problems with delivery and reporting, as there won't be the emergency of "someone's bought a ticket for a show tomorrow and the email hasn't arrived help!"

During this period, the marketing function in the old system won't have access to sales data for tickets sold in the new system. I hope that's not a showstopper; we can do incremental conversions of historical data for marketing and run marketing off of the new system if we have to.

Eventually, we reach the cut over date. The audience for the first show sold on the new system arrive, present their tickets, and are admitted. The old system can be switched off. The final historical marketing data from the old system can be converted. The new system is entirely live, with no scary crunch conversions and plenty of room for maneuver.