Moving from MB4 - 2000 clients, Nominet, Enom, WorldPay

[pdpd]

Hey All,

 

WHMCS looks like the answer to our MB nightmares.

 

We are going to make the switch, but have some questions;

 

We have around 2000 clients in MB4. We use WorldPay/FuturePay, ENOM and Nominet (Tag holders)

 

We are nervous about a full migration so will do this in steps. Firstly, install WHMCS on a separate subdomain and have all new customers sign up through that system (we'll use a new WorldPay install ID so callbacks work correctly etc. whilst the old install ID is still tied into MB4 to manage their FuturePay payments marking invoices etc).

 

After a month, we'll then start migrating customers across in blocks of say, 50 to make it smooth.

 

- Has anybody else done this, and any hints/tips? Or is it even safe to go for total migration?

 

- How do domain transfers and renewals work? Is it solid? As you know, MB is awful at managing domains and never reminds people correctly etc.

 

- How does the WorldPay integration work - is it solid? If we upgrade a customer package, does it automatically change the FuturePay amount for that customer or do we do it manually?

 

- Is the customer auto logged into Kayako if we integrate it, and do all the AJAX features work even though its on a separate subdomain?

 

I'm sure there's more, but it would be great to get some initial feedback,

 

Many thanks, and look forward to a less stressful life 80% of which is directly attributable to MB.

[chickendippers]

First off, congrats on making the right decision, having just completed our migration from MB4 to WHMCS I know you won't regret it!

 

- Good luck getting a new installation from WorldPay, we're still waiting for ours to work properly after a fortnight of tickets and phonecalls! Make sure you request Remote Admin on your new installation.

 

- The import script will import all your customers, packages, invoices, transaction history etc in seconds. My tips:

• After you've run the importer check the products/service screen and server config pages as this doesn't seem to be done flawlessly,
  
• If you use Varilogix Fraudcall you'll need to go through the database and remove the country codes from everyone's phone numbers due to a difference in the way WHMCS handles them.
  
• You'll need to go through the database and assign Enom the registrar to all your registered domains, as this didn't happen automatically to us.
  
• Invoices already created by MB that are imported have a slightly off product description (they have lots of random dates after the domain name), it's no biggie.

 

- WHMCS is perfect on domains, it sends out separate reminder emails and you can instruct customers how to renew domains (it's a manual process). Just make sure you delete any domain renewal invoices you import from MB.

 

- WorlPay integration knocks the socks off MB, it uses the limited agreement system which means you can take payments for any amount at any time - so it handles upgrades flawlessly.

 

- Haven't used Kayako so I can't comment; the built in support system is excellent.

[pdpd]

Many thanks for the detailed response - I really appreciate it

 

First off, congrats on making the right decision, having just completed our migration from MB4 to WHMCS I know you won't regret it!

 

It certainly looks that way from what I have read so far - oh the thought of never using MB4 again has put a very big smile on my face

Now I just need to work out the smoothest and quickest way to do it.

 

- Good luck getting a new installation from WorldPay, we're still waiting for ours to work properly after a fortnight of tickets and phonecalls! Make sure you request Remote Admin on your new installation.

 

Thanks for the tip. It looks like my original plan may not work as WorldPay have come back and said you cannot move customers from one agreement ID to another. So, we cannot migrate them easily without having them re-sign up which we really do not want to do. Will have to think through this one.

 

- The import script will import all your customers, packages, invoices, transaction history etc in seconds. My tips:

[After you've run the importer check the products/service screen and server config pages as this doesn't seem to be done flawlessly,

 

Thanks.

 

[*]If you use Varilogix Fraudcall you'll need to go through the database and remove the country codes from everyone's phone numbers due to a difference in the way WHMCS handles them.

 

Not using this so not a problem.

 

[*]You'll need to go through the database and assign Enom the registrar to all your registered domains, as this didn't happen automatically to us.

 

In MB we have a mix of mod_enom, mod_nominet and mod_other.

MB is awful at managing domains and we have multiple entries for many domains which causes all kinds of problems. So when it comes to renewal it screws up the domain entry with the package entry and the customer doesnt get an invoice raised.

Is life easier in WHMCS?

 

[*]Invoices already created by MB that are imported have a slightly off product description (they have lots of random dates after the domain name), it's no biggie.

 

Thats no major problem for us.

 

- WHMCS is perfect on domains, it sends out separate reminder emails and you can instruct customers how to renew domains (it's a manual process). Just make sure you delete any domain renewal invoices you import from MB.

 

Now that sounds amazing. How does it sync the expiry dates up? Does it work? Please tell me it works

How does it handle domain transfers - will it successfully synch the correct expiry date rather than set it to expire x years after the transfer in date (which is the wrong way, i.e. the MB way!). Will it synch all domains from different registrars correctly? i.e. Enom and Nominet for us?

 

MB makes a terrible mess of domains, especially as it has multiple entries for the same domains in a lot of instances and only ever updates the first one (if it does at all) which is usually an erroneous one. Also MB4 doesnt synch nominet domains at all. Its a nightmare.

 

 

 

- WorlPay integration knocks the socks off MB, it uses the limited agreement system which means you can take payments for any amount at any time - so it handles upgrades flawlessly.

 

Good grief - now that again sounds amazing

So it will auto debit the balance, and modify the FuturePay agreement also? I dont believe this til I see it working

 

 

- Haven't used Kayako so I can't comment; the built in support system is excellent.

 

We have Kayako and need to stick with it, so hopefully the integration is solid - it sounds like Matt does everything properly so I'm confident

 

Thanks again - nothing like advice from someone who has done exactly the same. Really appreciate it.

 

Sorry for the multiple smileys - I'm beginning to realise that 2008 may be the year MB4 hits the recycle bin and thats too good.

[chickendippers]

So when it comes to renewal it screws up the domain entry with the package entry and the customer doesnt get an invoice raised.

Is life easier in WHMCS?

This is one of the main reasons we switched.

Basically WHMCS will send reminder emails instructing the customer to go to the domain name management page and click "renew" - no invoice is generated until they do this, so no chance of it getting mixed up and terminating a hosting account for not paying a domain invoice.

 

Now that sounds amazing. How does it sync the expiry dates up? Does it work? Please tell me it works

From what I've gathered from around these forums it's not possible with the enom API, I can't comment on Nominet as we don't use it.

 

Good grief - now that again sounds amazing

So it will auto debit the balance, and modify the FuturePay agreement also? I dont believe this til I see it working

The created agreements have "no limit" on payment amount or interval; there is no recurring amount that needs modifying. But I don't have any experience of this because, as I mentioned, our new WP installation hasn't been setup properly.

[pdpd]

Once again many thanks.

 

From what I've gathered from around these forums it's not possible with the enom API, I can't comment on Nominet as we don't use it. .

 

OK - so where is WHMCS getting its expiry dates from? How does it know when to send a reminder? If someone transfers in a domain, how does it know when that domain expires?

 

The created agreements have "no limit" on payment amount or interval; there is no recurring amount that needs modifying. But I don't have any experience of this because, as I mentioned, our new WP installation hasn't been setup properly.

 

OK - so this is a separate system to FuturePay?

 

Thanks

[Si]

We made the exact same move as you are planning in august this year (2007). Nominet tag holders, Enom, Paypal and Worldpay.

 

The WHMCS import script was great, but it took approximately 8 weeks of fine tuning and testing it before we actually went live with ALL customers in one go in late October. This was the only way to do it for us. (1200+ customers).

 

The biggest issue though was domain dates etc and it does depend on your business model in MB4. We used to invoice domains 60 days prior to renewal date so our renewal/expiry dates in domains were not correct. So, we cross referenced the dates with a CSV from enom and nominet and dumped them into the mySQL DB in WHMCS. We changed all customers emails to our own email address during the testing of WHMCS so that they didn't receive email notifications. After 10 days of tweaking things, we were ready to go.

 

We did use kayako before, but were never totally happy with the MB4 integration (various issues), so we dumped it and now use the inbuilt support within WHMCS and find it is more than adequate for our needs. No customer complaints 3 months on either.

 

The only major issue we had then, after going live, was, as you have stated, the futurepay agreement was not the same for the WHMCS model. So, after several telephone discussions with Worldpay support (awesome imho), we decided on the following course of action:

 

we set up the futurepay system on WHMCS and tested it to ensure it was working, (as per the manual). Then, we used the Futurepay online CP to list all of our futurepay agreements and cancelled each one of them. At the same time, we copied and pasted an email to each customer as we cancelled their futurepay agreement. This basically told them it was to improve our service to them and that on their next invoice notification from us, they should login and pay it by setting up a new agreement.

 

It took some time to do this. Well, 2 days. But in the end, 2 months later we have every single one of those customers with futurepay agreements, signed up and on the new system, which is far far better. They all understood the reasoning and it was really flawless.

 

Worldpays system also emailed them to advise the FP agreement was cancelled, so its important to email the customers instantly the moment you cancel the agreement (or beforehand) to ensure they know why its happening and don't bombard your support desk with questions.

 

We were prepared to spend 3 months 'nursing' the system to ensure the notifications and cross-over of domain renewals etc went smoothly. That would have taken us to Christmas. We had a few minor issues, which were really down to the learning curve we had with WHMCS and not software issues, which wasn't a bad thing.

 

We would not look back.

 

Its been 5-6 months of work to ensure we pulled it off with little upset to customers and I have to say it has been well worth it. Sales are up, customers love the new interface and we have more of our business automated without any of the crap we had with MB.

 

Good luck....but make the move!

 

Happy Christmas!

 

Si

[pdpd]

Hi Si,

 

Brilliant - some really valuable advice here.

 

The WHMCS import script was great, but it took approximately 8 weeks of fine tuning and testing it before we actually went live with ALL customers in one go in late October. This was the only way to do it for us. (1200+ customers).

 

Interesting - so how did you maintain the sync during those 8 weeks? Or did you synch twice? (at 0 days and at 8 weeks?)

Did your MB stuff not go out of synch with WHMCS during this period?

 

 

The biggest issue though was domain dates etc and it does depend on your business model in MB4. We used to invoice domains 60 days prior to renewal date so our renewal/expiry dates in domains were not correct. So, we cross referenced the dates with a CSV from enom and nominet and dumped them into the mySQL DB in WHMCS. We changed all customers emails to our own email address during the testing of WHMCS so that they didn't receive email notifications. After 10 days of tweaking things, we were ready to go.

 

Great - we use a weekly cron to synch ENOM and NOMINET expiry dates live from their data. This doesnt work properly in instances where MB has multiple entries for the same domain (which it does a lot).

 

The only major issue we had then, after going live, was, as you have stated, the futurepay agreement was not the same for the WHMCS model. So, after several telephone discussions with Worldpay support (awesome imho), we decided on the following course of action:

 

we set up the futurepay system on WHMCS and tested it to ensure it was working, (as per the manual). Then, we used the Futurepay online CP to list all of our futurepay agreements and cancelled each one of them. At the same time, we copied and pasted an email to each customer as we cancelled their futurepay agreement. This basically told them it was to improve our service to them and that on their next invoice notification from us, they should login and pay it by setting up a new agreement.

 

If only they would allow us to move customers between 2 installation ID's that would be perfect, but alas no

We'd prefer not to go through the same process you outline, and WP are now mentioning Dynamic Callbacks. We'll have to look into that!

 

Good luck....but make the move!

 

Happy Christmas!

 

Si

 

Brilliant and many thanks - we are certain MB is a sinking ship, we had a ticket a couple of years ago that took nearly FOURTEEN MONTHS for them to answer. Ridiculous. They pulled their support together about a year ago, but then it seems to have slipped again recently a little. Now its just bloated, slow, and essentially unusable for our needs.

 

Merry Christmas to you - I really appreciate you taking the time to outline your experience,

[Si]

Brilliant - some really valuable advice here.

 

Interesting - so how did you maintain the sync during those 8 weeks? Or did you synch twice? (at 0 days and at 8 weeks?)

Did your MB stuff not go out of synch with WHMCS during this period?

 

 

We didn't sync at all during those few weeks. We simply made a 'map' / 'sequence' of sql steps that had to be made after we ran the import script that WHMCS provides. Then when we were convinced we had it 100% and could do it for real, we did it at about 2am one morning. All in all, it took about 30 minutes of downtime where MB was shut down, and before we went live with WHMCS and uploaded a 'new'/updated site with our html code reflecting the WHMCS links.

 

There were 2 of us that did all of this, so with a team of more, you may be able to it quicker. I find a small team easier to work with.

 

I did the site integration and another colleague did the DB work, and we both tested and tested and tested. There's quite a lot to ensure you get sorted in any sort of a move like this, right down to htaccess mod rewrites for urls etc - so don't be in any hurry, just take your time and get it right.

 

We initially messed up the domain import and hadn't changed the customers emails to ours. Domains that had 'expired' in MB had their dates set to 1970 in WHMCS and were 'active or suspended' (I can't remember which now) and that meant WHMCS ran invoicing for them when the cron ran. Some customers ended up with invoices for expired domains and it billed them as if they had to pay 37 years worth of renewals.

 

Silly things like that are lessons you should learn of people like me and not in real life lol

 

1) Change your customers emails to an email of your own

2) Then set up your cron job

 

 

Its funny now and most customers thankfully understand these things happen, but we had a few dozen support tickets we could have done without that day.

 

Si

[pdpd]

Thanks again Si - again, very useful. We are building up a list of things to check for when we go for it!

 

If you think of anything else at all we should be aware of, I'd love to hear it.

 

We are looking at making the switch in January sometime - the sooner we are away from MB the better!

[TheHostingHeroes]

hi

 

we moved from MB4 to WHMCS early November. It was the best move ever, WHMCS is a fantastic billing system and its worldpay integration is great.

 

Like menionted above, make sure you get remote admin on your futurepay installID. (i got it over the phone).

 

The only problem was, we had to manually cancel every MB4 futurepay agreement to have everyone setup new agreements within WHMCS.

 

Kayako aint working properly yet with the integration and even the latest CVS still doesnt have problems fixed.

[othellotech]

- Good luck getting a new installation from WorldPay, we're still waiting for ours to work properly after a fortnight of tickets and phonecalls! Make sure you request Remote Admin on your new installation.

 

You must be doing something wrong It took a total of 18 minutes from sending the email requesting the new install-id, to getting one setup, phoning them saying it was replacing an existing id, to being activated

 

Being a WP partner will have helped us in that respect, but if it's taken you >3 days then something is very wierd, as they can do the whole thing in a single phonecall and an email confirmation.

 

I have a couple of bugs with both the FuturePay and PayPalSubscriptions to report to WHMCS but in the main its fine.

 

To the OP, you will want to do the import over and over until it goes right, a lot of the data may need correcting either in the source system, or before letting the clients at it - the WHMCS manual pages will tell you how to wipe the clients/orders/etc but that leaves a lot of duplicated config information behind - better to restore to a known good blank DB between import runs.

[pdpd]

Thanks for the feedback.

 

hi

The only problem was, we had to manually cancel every MB4 futurepay agreement to have everyone setup new agreements within WHMCS.

 

Why was this? We absolutely do not want to have to do this. Can we not just change the callback URL in our WorldPay area once we have made the switch? Or is the above necessary when activating FuturePay Limited Agreements?

[pdpd]

To the OP, you will want to do the import over and over until it goes right, a lot of the data may need correcting either in the source system, or before letting the clients at it - the WHMCS manual pages will tell you how to wipe the clients/orders/etc but that leaves a lot of duplicated config information behind - better to restore to a known good blank DB between import runs.

 

Thanks!

 

We are planning on hiring WHMCS to assist us during the import - what particular information were you finding was duplicated and particularly problematic?

 

Also, did you do this live and make the switch or did you keep with MB4 in the interim and keep synching whilst both systems were running until you were happy?

[Si]

Thanks for the feedback.

 

 

 

Why was this? We absolutely do not want to have to do this. Can we not just change the callback URL in our WorldPay area once we have made the switch? Or is the above necessary when activating FuturePay Limited Agreements?

 

Because WHMCS using the Futurepay Limited Agreement which is totally different than the Futurepay agreement used by MB. The WHMCS system is much better incidentally.

 

The agreement you have with your clients is not a Futurepay Limited Agreement, so you cannot use the agreement ID's. They are useless in WHMCS.

 

You need to set up your futurepay system as shown in the manual, with the extra hidden futurepay id in your clients accounts, ask worldpay to set up a remote login for your futurepay limited agreement - takes about 60 minutes for them to do - and once you've tested it, and you know you have it set up properly, you WILL need to cancel the old agreements and ask each customer to login and manually pay their next invoice and setup a new agreeement.

 

Explain the reasons why (benefits) to your customers, and they will understand. At least ours did. It wasn't a big deal really and the benefits outweigh the little bit of hassle.

 

Si

[pdpd]

Thanks for the update Si,

 

Hmm this presents a big problem for us. We are dealing with over 2500 FP agreements, and cannot have all these customers re-sign up. So - we are a bit stuck

[arcdigital]

It could work for you, because i'm sure the 2500 FP agreements aren't from the same customers. You would just need to get each of them to pay an invoice, takes 5 mins.

[Si]

Thanks for the update Si,

 

Hmm this presents a big problem for us. We are dealing with over 2500 FP agreements, and cannot have all these customers re-sign up. So - we are a bit stuck

 

arcdigital is correct in that. Plus, right now, you will have to manually have to watch for each futurepay payment coming in and mark each invoice paid anyhow. Even if you took each one as they happen over the next month, and cancelled them I'm sure at the end of one month you would have a massive hole in that 2500.

 

We had customers with 5+ individual account agreements on the old system who now only have/need the one. No matter how many you have, make an action plan and clear it. It may be a 'big job' for you, but its only a little deal for your customers to pay one invoice. Its def worth it.

 

Si

[isdoo]

This is one of the main reasons we switched.

Basically WHMCS will send reminder emails instructing the customer to go to the domain name management page and click "renew" - no invoice is generated until they do this, so no chance of it getting mixed up and terminating a hosting account for not paying a domain invoice.

 

Not sure this is true - the invoices are generated automatically and reminders are sent - but these are independant.

 

Not sure how you have yours set-up to only send invoices if the user goes in and selects renewal.

 

Or have I mis-understood you?

[pdpd]

We had customers with 5+ individual account agreements on the old system who now only have/need the one. No matter how many you have, make an action plan and clear it. It may be a 'big job' for you, but its only a little deal for your customers to pay one invoice. Its def worth it.

 

Thanks.

 

Can you clarify - assuming this scenario:

 

- A customer has 2 packages, one is paid for on 3rd of the month (say £4/month) and the other on 20th of the month (say £6/month).

 

Under the new FP system in WHMCS would this customer have to pay both invoices when they were generated? Or would they pay only one, and the limited agreement would be tied to that customer and automatically take payments for all their accounts automatically when invoices were raised?

 

At the moment we are thinking of having some custom coding done so that our old FuturePay callbacks still work by marking our WHMCS invoices as paid, whilst all new customers can have their agreements set up on the new system. If any older customers have FP agreements that expire, they can login and pay invoices manually and move to the new system. Due to the fact almost all cards will expire in the next 2 years, by that time everyone should be on the new system?

[Si]

Thanks.

 

Can you clarify - assuming this scenario:

 

- A customer has 2 packages, one is paid for on 3rd of the month (say £4/month) and the other on 20th of the month (say £6/month).

 

Under the new FP system in WHMCS would this customer have to pay both invoices when they were generated? Or would they pay only one, and the limited agreement would be tied to that customer and automatically take payments for all their accounts automatically when invoices were raised?

 

Once the customer pays for 1 invoice and sets up a new FP agreeement, all future invoices on other services on that account can be set automatically to be raised as futurepay (by having admin change the setting on the payment method of the product to futurepay), or by the customer logging in and changing the payment method on the invoice to Futurepay themselves.

 

Once a single agreement is in place, when the customer selects Futurepay on any new invoices, they cannot make another FP agreement as the system tells them we have their card details on file and the invoice will attempt to debit their card on the invoice due date. Its just beautiful.

 

At the moment we are thinking of having some custom coding done so that our old FuturePay callbacks still work by marking our WHMCS invoices as paid, whilst all new customers can have their agreements set up on the new system. If any older customers have FP agreements that expire, they can login and pay invoices manually and move to the new system. Due to the fact almost all cards will expire in the next 2 years, by that time everyone should be on the new system?

 

Good luck with this, although not one to pour a dampener on any efforts to make life easier, but I'm sure there is some reason why this won't work or else others (including Matt) would have suggested it to the many others who have already gone down this route.

 

There are 3 flaws that I 'think' exist in your 'custom coding' option. Others might want to clarify if I'm right (or not).

 

One flaw I can see is that when a customer's card expires, Worldpay will have been emailing them to ask them to login to their worldpay account to update their card details, and when they do, their original agreement continues. So I don't think the scenario you describe is likely to happen. Cards might expire, but the FP agreements don't. That's the job of worldpay to keep the original agreement on the original card alive.

 

The second flaw is that even if your custom coding works, I think you're gonna end up with a lot of confused customers. How do you write a knowledgebase article advising customers of how they operate their futurepay agreement with you?

 

Thirdly, lets say I'm a customer with an old agreement and I sign up a new hosting account and create a new fp agreement, how do all other invoices raised on my account now with futurepay as a payment option get treated?

 

1) Worldpay will be sending payments automatically as they always have on the anniversary date

2) WHMCS will now also be requesting payment from their card on the invoice due date.

 

You gotta go with one or the other IMO and there's now other option.

 

Maybe someone like Matt can comment on your custom code idea further.

 

Good luck.

 

Si

[pdpd]

Thanks Si, some great points there.

 

Oh how great it would be if WorldPay would allow us to just somehow switch the agreement type over for all our agreements. I can see why this is not possible, but its good to dream!

 

If anybody has any other possible suggestions for somehow not having to go through the FuturePay cancellation routine for all our agreements, would love to hear them.

[pdpd]

Two other quick queries on these limited FP agreements,

 

1. Say a customer upgrades from a £3/month package to a £5/month package. Can they do this themselves in their client area or do we have to do it? And if they upgrade say half way through the month (so there is a pro-rata balance of £1 to pay before the next billing invoice of £5) - is this taken automatically, immediately? Or is it added to the next invoice?

 

2. If we go down the route of cancelling all our FP agreements and having them signup to the new limited agreements, do we have to wait until an invoice is generated before they can sign up? Or is there another way. I'm wondering if we do both - i.e. create the custom coding to handle existing agreements (which is not ideal) AND try and move everyone across by having them sign up on a new limited agreement (and only then once they have done this, cancelling the old one). This way if we cant get hold of a customer for any reason to switch them, at least the existing FP agreement is in place which is better than nothing? Thoughts?

 

Actually, those arent quick queries at all - sorry

 

But, huge thanks again - so sorry for all the questions, we just cant afford to get this wrong...! Feedback from real life users who've been down this path is invaluable. Desperately trying to get away from MB4 whatever it takes!

[Si]

Two other quick queries on these limited FP agreements,

 

1. Say a customer upgrades from a £3/month package to a £5/month package. Can they do this themselves in their client area or do we have to do it? And if they upgrade say half way through the month (so there is a pro-rata balance of £1 to pay before the next billing invoice of £5) - is this taken automatically, immediately? Or is it added to the next invoice?

 

Yep, clients upgrade automatically themselves and any pro-ratas are caculated and added to the invoice. If they are futurepay customers and they select futurepay for the upgrade, the higher charge will be debited from their card on the invoice due date.

 

2. If we go down the route of cancelling all our FP agreements and having them signup to the new limited agreements, do we have to wait until an invoice is generated before they can sign up? Or is there another way. I'm wondering if we do both - i.e. create the custom coding to handle existing agreements (which is not ideal) AND try and move everyone across by having them sign up on a new limited agreement (and only then once they have done this, cancelling the old one). This way if we cant get hold of a customer for any reason to switch them, at least the existing FP agreement is in place which is better than nothing? Thoughts?

 

Actually, those arent quick queries at all - sorry

 

But, huge thanks again - so sorry for all the questions, we just cant afford to get this wrong...! Feedback from real life users who've been down this path is invaluable. Desperately trying to get away from MB4 whatever it takes!

 

You (or rather they) have to wait until their next invoice is generated and make a manual payment on it, setting up their new futurepay agreement in the process.

 

Si