Whmcs Migrator (Beta) - Updated 2013-11-12

[Cody]

Would it be possible mate, to pick the salt up and try to de-salt it using the method whmcs used and then rehash them into Blesta's?

 

It is possible to reveal the original passwords using hashcat, but not something worth even trying. It would be much much easier to update authentication in Blesta to allow WHMCS client passwords to work.

 

 

/app/models/users.php (line 234) from:

elseif (Configure::get("Blesta.auth_legacy_passwords") && $user->password == md5($vars['password'])) {

 

to:

elseif (Configure::get("Blesta.auth_legacy_passwords") && ($user->password == md5($vars['password']) || ($parts = explode(":", $user->password) && $parts[0] == md5($parts[1] . $vars['password'])))) {

[tsiedsma]

My import appears to have completed by when I looked at the page to view the results, it was on the Import Manager page where I would chose the WHMCS 5.2 importer or the Blesta 2.5 Importer.  I clicked back I think and now it is trying the import again.  Might be nice to have the import redirect to a completed page with results (stats) of the import and no way to accidentally press back and restart the migrator...

 

No idea on the results yet, or the actual length of time it took since the page redirected oddly.  It was likely just over 2 hours like last time.

 

Edit:

No services, packages or support stuff.

[FRH Dave]

Getting ready to try v5.

 

Regarding the passwords, I think the best way is to require all users to reset their passwords after the migration.  That's the most secure and simple method, IMHO.

[FRH Dave]

I'm working through some other entries, but AT FIRST GLANCE, it looks like the pricing information is correct except as noted below.  Balances appear to correctly reflect configurable options and promotional pricing.  I'll need some time to do a more detailed audit, but on the surface, we're so close I can taste it.  Two more hiccups that I see right now.  Can't promise more won't come up during the audit:

 

First:  The invoice PDF still does not reflect account credits as partial payments.  The invoice PDF for the transaction below shows no payments at all.  No PDFs show payments at all other than the "PAID" watermark.  If this is functioning as designed, I'll go submit this as a feature request.  But it should at the very least reflect account credits applied, otherwise we get into invoice padding where we're submitting an invoice for an inflated amount.

 

Second:  We're still seeing an issue with some old invoices, with a twist.  A client has an invoice from 7/7/12 in the amount of $208.97.  An existing account credit of $24.99 was applied, leaving the client responsible for $183.98.  The client paid $208.97 -- he paid the invoice in full, causing the $24.99 to carry over to his next invoice.

When imported, Blesta says that he paid $24.99 and owes $183.98.  This MIGHT be because the original invoice in WHMCS has a negative balance due, because of the credit that gets carried forward.  When I view the transaction in Blesta, it shows Type = Other, Amount = $208.97, Credited = $208.97, Applied = $0.00, Number = (a valid PayPal transaction #, I assume), status = Approved, date = July 07 2012 9:08:15 AM.  That's interesting, because usually the payment shows up in the "Applied" field.

[tsiedsma]

My import completed again, but with no status, it just dumps me to this page once completed.

 

I am still not seeing any client services, no system packages and no support departments or tickets.

 

[tsiedsma]

Ohh wow, just noticed this on the Browse Clients page...  Each client in the db has an auto incremented client id, not sure what this is all about...

This makes it impossible to manage clients from within blesta.  Also seeing it on the invoices page.

 

[DandyDandy]

Admin passwords in WHMCS are interestingly slightly less secure than their client passwords. They are MD5, and can be supported by enabling legacy password support in config/blesta.php. Client passwords on the other hand are salted, and Cody says they can be supported if we make a core change to Blesta to support both legacy MD5 and the ones WHMCS uses. We haven't decided if this is something we want to do yet.

 

Once you have imported all client accounts from WHMCS is there a way possible to send out a mass password change Via email some how to all clients?

[Cody]

I'm working through some other entries, but AT FIRST GLANCE, it looks like the pricing information is correct except as noted below.  Balances appear to correctly reflect configurable options and promotional pricing.  I'll need some time to do a more detailed audit, but on the surface, we're so close I can taste it.  Two more hiccups that I see right now.  Can't promise more won't come up during the audit:

 

First:  The invoice PDF still does not reflect account credits as partial payments.  The invoice PDF for the transaction below shows no payments at all.  No PDFs show payments at all other than the "PAID" watermark.  If this is functioning as designed, I'll go submit this as a feature request.  But it should at the very least reflect account credits applied, otherwise we get into invoice padding where we're submitting an invoice for an inflated amount.

 

The PDF invoice templates shipped with Blesta do not display transactions.

 

Second:  We're still seeing an issue with some old invoices, with a twist.  A client has an invoice from 7/7/12 in the amount of $208.97.  An existing account credit of $24.99 was applied, leaving the client responsible for $183.98.  The client paid $208.97 -- he paid the invoice in full, causing the $24.99 to carry over to his next invoice.

When imported, Blesta says that he paid $24.99 and owes $183.98.  This MIGHT be because the original invoice in WHMCS has a negative balance due, because of the credit that gets carried forward.  When I view the transaction in Blesta, it shows Type = Other, Amount = $208.97, Credited = $208.97, Applied = $0.00, Number = (a valid PayPal transaction #, I assume), status = Approved, date = July 07 2012 9:08:15 AM.  That's interesting, because usually the payment shows up in the "Applied" field.

 

This is because Blesta, unlike WHMCS, does not allow an invoice to be overpaid. So, what happened was because the transaction for 208.97 would have overpaid the invoice, Blesta prevented that transaction from being applied in full. Instead, what will happen is Blesta will apply as much of that transactions as possible to any open invoices (beginning with oldest unpaid) when the apply credit cron task runs.

[Cody]

My import completed again, but with no status, it just dumps me to this page once completed.

 

I am still not seeing any client services, no system packages and no support departments or tickets.

 

For support tickets, run the following query, if you have any results the import worked, you just need to set permissions to access the support groups for your currently logged in user (the importer can only set permissions on users it imported):

 

SELECT * FROM `support_tickets`

 

As for services, there won't be any if there was an issue importing packages, and no packages if there was an issue with modules. Are you sure you have PHP error reporting enabled? If you're not seeing a success message the import was definitely not a success.

[tsiedsma]

For support tickets, run the following query, if you have any results the import worked, you just need to set permissions to access the support groups for your currently logged in user (the importer can only set permissions on users it imported):

 

 

SELECT * FROM `support_tickets`

 

As for services, there won't be any if there was an issue importing packages, and no packages if there was an issue with modules. Are you sure you have PHP error reporting enabled? If you're not seeing a success message the import was definitely not a success.

 

Like I said, it redirects to the import manager screen and no longer reports success or failure.

 

As for support departments:

[Cody]

Once you have imported all client accounts from WHMCS is there a way possible to send out a mass password change Via email some how to all clients?

 

Each password reset email is unique per the user that receives it, and expires after a certain amount of times, so no mass message can be sent and it's generally not a good idea to send such a message if a user isn't expecting to receive it. However, there's no need to change the password imported since it won't work. Instead, users can request a password reset from the login screen.

[tsiedsma]

Each password reset email is unique per the user that receives it, and expires after a certain amount of times, so no mass message can be sent and it's generally not a good idea to send such a message if a user isn't expecting to receive it. However, there's no need to change the password imported since it won't work. Instead, users can request a password reset from the login screen.

 

I would rather send a mass email to all of my customers with instructions that their passwords have been expired and they must login to the new Blesta system to request a password reset.

Is that an option, I don't see any mass mail features anywhere.  Perhaps I am overlooking it.  Of course I need a successful migration first.

[Cody]

Like I said, it redirects to the import manager screen and no longer reports success or failure.

 

It's supposed to redirect. But the fact that you see no success message, and you're missing data indicates an error is occurring. Make sure you have PHP error reporting enabled, and display errors on. Without an exact copy of your database, or a specific error to look at I can't do anything but guess as to what's going on.

[tsiedsma]

It's supposed to redirect. But the fact that you see no success message, and you're missing data indicates an error is occurring. Make sure you have PHP error reporting enabled, and display errors on. Without an exact copy of your database, or a specific error to look at I can't do anything but guess as to what's going on.

My PHP configuration has not changed since my previous attempts to migrate.  Do I need to change a setting in Blesta to output errors?  I don't have anything logged to an error_log file either which is typical on my server when PHP has an error and the app doesn't turn off error reporting.

[FRH Dave]

This is because Blesta, unlike WHMCS, does not allow an invoice to be overpaid. So, what happened was because the transaction for 208.97 would have overpaid the invoice, Blesta prevented that transaction from being applied in full. Instead, what will happen is Blesta will apply as much of that transactions as possible to any open invoices (beginning with oldest unpaid) when the apply credit cron task runs.

 

So what happens in the following scenario:

 

1) Client has invoice for $250.00

2) Client has existing account credit for $20, which is automatically applied to the invoice

3) Client now owes $230.00

4) Client's PayPal subscription comes in for $250.00

 

If what you're saying is that the $20.00 will be applied towards the oldest open invoice, that's fine.  That's how WHMCS works.  But in the meantime, the client (in Blesta) is being advised he has an overdue balance.  We can't test this without firing off cron, which is a bad idea -- all the client emails addresses are in there, and I don't want our entire userbase getting confusing emails from Blesta since it isn't live yet.

 

What's more confusing is that the invoice was overpaid by $24.99, not by $183.98.  To make this right, the client's account should have been credited for $24.99.  In fact, since this is an ancient invoice that's already paid in full, and since the client currently has no account credit, and given the circumstances (rescuing data from WHMCS), it should just accept WHMCS's starting accounting data as golden.

[tsiedsma]

So what happens in the following scenario:

 

1) Client has invoice for $250.00

2) Client has existing account credit for $20, which is automatically applied to the invoice

3) Client now owes $230.00

4) Client's PayPal subscription comes in for $250.00

 

If what you're saying is that the $20.00 will be applied towards the oldest open invoice, that's fine.  That's how WHMCS works.  But in the meantime, the client (in Blesta) is being advised he has an overdue balance.  We can't test this without firing off cron, which is a bad idea -- all the client emails addresses are in there, and I don't want our entire userbase getting confusing emails from Blesta since it isn't live yet.

 

What's more confusing is that the invoice was overpaid by $24.99, not by $183.98.  To make this right, the client's account should have been credited for $24.99.  In fact, since this is an ancient invoice that's already paid in full, and since the client currently has no account credit, and given the circumstances (rescuing data from WHMCS), it should just accept WHMCS's starting accounting data as golden.

 

If I wanted to test things like you, I would either set all clients email addresses to something @mydomain and setup a catchall.  Either that or completely disable outgoing mail on your test server.

[Michael]

Why not edit the template for the order emails.

 

This is a email from our new billing system in testing, we apologies for the inconvenience please ignore this email until further information. 

 

on the Account Registration | Invoice Notice (1st) | Service Creation templates.

[tsiedsma]

Why not edit the template for the order emails.

 

This is a email from our new billing system in testing, we apologies for the inconvenience please ignore this email until further information. 

 

on the Account Registration | Invoice Notice (1st) | Service Creation templates.

 

Because it will still cause confusion.  Dave is right to not want to run the cron or have his clients receive emails like that.

It will generate lots of unnecessary tickets, it could also potentially cause termination of services if the cron run determines accounts need to be terminated or suspended.

I'd disable the modules too, or set them in sandbox mode if applicable.

[Cody]

So what happens in the following scenario:

 

1) Client has invoice for $250.00

2) Client has existing account credit for $20, which is automatically applied to the invoice

3) Client now owes $230.00

4) Client's PayPal subscription comes in for $250.00

 

If what you're saying is that the $20.00 will be applied towards the oldest open invoice, that's fine.  That's how WHMCS works.  But in the meantime, the client (in Blesta) is being advised he has an overdue balance.  We can't test this without firing off cron, which is a bad idea -- all the client emails addresses are in there, and I don't want our entire userbase getting confusing emails from Blesta since it isn't live yet.

 

What's more confusing is that the invoice was overpaid by $24.99, not by $183.98.  To make this right, the client's account should have been credited for $24.99.  In fact, since this is an ancient invoice that's already paid in full, and since the client currently has no account credit, and given the circumstances (rescuing data from WHMCS), it should just accept WHMCS's starting accounting data as golden.

 

Just disable all tasks except the apply credits task. [settings] > [Company] > [Automation]. I don't believe any emails are sent for apply open credits, but if you want to be certain, update your mail settings ([settings] > [Company] > [Emails] > [Mail Settings]) to use invalid SMTP info. To be doubly sure no emails go out, disable email templates in [settings] > [Company] > [Emails] > .

 

Also, if you don't feel confident enabling cron tasks you can choose to explicitly run the "applyCredits" task by passing the cron key along to the cron via a GET request:

 

https://yourdomain.com/blesta/cron/applyCredits/?cron_key=YOUR_CRON_KEY

[tsiedsma]

Ran the importer again, made it through all clients, contacts, invoices and transactions.  Didn't import any client services, support departments or tikcets, hosting packages or domain packages.

The importer completed on the importer selection page with the message that it completed successfully.  I forced display_errors to on as well as error_reporting but the importer redirects when it completes which is indicated by the fact that the import took over 2 hours but the page was generated in less than a second.

 

See my post above, all client ids are missing still. - Edit: Fixed the view, re-uploaded everything, must have been something corrupted...

[Paul]

You could also choose SMTP for the delivery type, and fill in bogus information. To be certain no credit cards could be charged, set a passphrase under Settings > Company > General > Encryption. Setting a passphrase encrypts the private key, making decryption of card numbers impossible without it and requiring batch processing. The passphrase can be removed anytime (with the current passphrase, of course).

[twhiting9275]

Ok, no response to my issues. Works for me.

Remember, you're losing customers by just ignoring them like this.

 

I'll find someone that does want my money

[Michael]

Ok, no response to my issues. Works for me.

Remember, you're losing customers by just ignoring them like this.

 

I'll find someone that does want my money

 

Jeez there's loads of customers in this thread, give them a chance god.

[tsiedsma]

Ok, no response to my issues. Works for me.

Remember, you're losing customers by just ignoring them like this.

 

I'll find someone that does want my money

 

 

Jeez there's loads of customers in this thread, give them a chance god.

 

twhiting9275, I've had your back everywhere else, but these guys have been great about releasing new updates to their "BETA" importer.  It isn't perfect as you can tell but they are making great effort to resolve the issues.

Obviously its in their best interest to perfect a WHMCS importer if they want to take in all of the refugees.  Don't take your anger at WHMCS out of the Blesta devs.  They are doing fantastic work considering all of the demands and issues in this thread alone.

[tsiedsma]

I just found an issue with invoices.

Apparently Blesta thinks an invoice is past due when it was marked as Refunded with WHMCS.

 

I was looking at my past due invoices in Blesta and noticed a couple of odd ones.  I looked them up in WHMCS and they were marked as Refunded.

 

The problem I see is that even a Paid invoice that was partially refunded is marked as Refunded.  So you can't just import refunded invoices as voided or paid, you have to look at each invoice and make that determination.