Key Points for a Successful Ad Server Migration

Editor’s Note: As your business evolves and changes so should your revenue and operations tools. You may find it makes sense to upgrade or switch your tools. This will lead to the dreaded ad server migration. Neil Rigby, Head of Operations at Associated Newspapers Ltd. recently compiled some tips on migrations which he recently shared with the members. He has kindly let us repost these tips here.

Migrations.  My favourite.  Sometimes I just do them to keep things interesting.  I jest.

They tend to have a bad rep but aren’t the scary beast most folk think they are, if you know the right teeth to pull.  If you consider the hint’s and tips below you won’ t go far wrong.

1)  Don’t do it all by yourself.  Get a good Project Manager on board and delegate as much of the timeline and waypoint process to them.  It’s also fun watching a good PM hammering a bunch of Devs who think they have to get the parts in from Japan.  A brilliant PM will keep you on your toes too.

2)  The kick off meeting is key.  Ingredients:  You, the PM, one sales manager, maybe one Dev for seasoning.  You will need involvement of any peripherals that plug into the adserver too, like Fivia or Solbright.  The PM will create the timeline and tasks. You should meet at least once a week to discuss progress.  From this meeting you should really obtain that ‘line-in-the-sand’ for the migration.  Get everyone to sign up to it.  And come hell or high water, stick to it.

3)  Ad Tags.  Without knowing what your moving to and from, the main trick to this remains don’t change what you don’t have to.  Just over a year ago we moved from Atlas to DfP.  I left all the AREA=, SUBAREA= and a bunch of other custom tags exactly the same from adserver to adserver.  This meant the salespeople would still instinctively understand most of the ‘incoming’ terminology simply because it didn’t change.  We ended up only changing the domain call, the fact that DfP uses Zones, and that it had some other stickies like sz=, tile= and er… that’s it I think.

4)  Don’t necessarily use the exercise to ‘completely overhaul your network set-up”.  Migration first, revamp second.  Unless it’s a recognised disaster area you can over complicate the migration project with a fix for the sake of fixing approach.  Quite often through the reason for the change is better functionality in ad tag granularity and you will wish to take a long hard look at this area; nevertheless, remember one of the golden rule of migrations:  don’t change what you don’t have to.

5)  As the work progresses (and as an option) use the Sales Manager(s) to communicate to agencies and advertisers that you are migrating.  Doesn’t matter how this is done, formally or not, they’ll know how to manage those relationships.  Do not publish the migration date though.  That is for internal use only.

6)  Front end migration.  In other words the donkey work of shifting Orders and Placements from one UI to the other.
        (i)  Create as many pertinent advertisers as necessary before the switch date, i.e only the ones that will be live.  Don’t do all of them.
        (ii)  If there is more than one of you, get each other QA the others’ campaigns.  If you’re one man band, leave it 24 hours before double checking if possible.
        (iii)  Don’t earn yourself an aneurysm by worrying about the amount of impressions to carry over on CPM campaigns.  Put in the TOTAL impression goal.  I know that sounds crazy.  But when it comes to migrations any impression to a 3rd Party count is a good impression.  In my experience, I’m sorry to say, some agencies will use all the tricks to say you underdelivered just because of the migration.  Don’t give them the ammo.  Trust me, over a 24 hour period, you won’t massively over deliver anyway.
        (iv)  After 24 hours, then you manage the impression balance from adserver to adserver.  You’ll be amazed at how things remain/become stable and that you hit targets pretty much on the nose with a ‘bump’ in the middle…

7)  Enjoy the project.  You’re doing it for all the right reasons after all.

8)  Go for beers, slap the PM on the back.

Seriously, I led the team that migrated about 100 of our sites in under 4 weeks this time last year.  And believe it or not, yesterday I added a partner site, working with admittedly a pretty good Dev in under a working day, all over email.  In both cases I adhered to at least 6 of the points above…

You can judge a good migration but how many people noticed it.  If they didn’t, you’ve succeeded.