The two things I worry most about in an implementation are:
1. Payment Systems
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
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.
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.