tsiedsma

If anyone knows of Steven from Rack911, he told me that WHMCS is not as bad as people are saying and that others hosting billing solutions and control panels are worse. He also told me that if I were to pick one billing solution based on security alone, Blesta is hands down the best choice. This is one reason I keep helping Blesta with this importer. Maybe not with code, but by testing it and reporting my findings. I have a huge database and I know that i am not alone. If they can make mine work well, others will benefit from it down the line.

Almost everything imported for my test group. A couple of issues. Servers are listed but show 0 accounts.Editing and saving the server details causes the number of accounts to populate Server default name servers were not imported Server Label and Server Hostname are the same, WHMCS has Server Name and Server Hostname which I would expect to be imported respectively. Support stuff came over but there is no Support option in the header even though the support manager is installed.(Default Admin group doesn't get assigned permissions to the support manager) Some packages have odd pricing. I'm seeing some with duplicate terms like Monthly but with two prices and only one is accurate. Some packages have quantity available set to zero even though WHMCS had stock control unchecked. All tickets came over as Open and the Ticket Number doesn't show up in the Ticket list.

I just ran another import, well it just finished anyways. Even with your default values and the fact that I set all empty last names to Smith, I still got the error:

I think one of the issues with the importer taking so long has to do with the transactions. It appears to pull them all over, then loop through each one and apply payments to invoices. I monitored mysql and noticed that this took a significant amount of time as temp tables were created and queries performed. Is there anyway to simplify or dumb down this process? It seems like there are a ton of queries for each transaction. After reducing my test database for WHMCS to 2,000 clients, it still took over an hour which tells me my initial import was dying after 2 and a half hours before ever getting to the packages.

The better way to handle this is to make temporary maps of new entries to the old WHMCS entries so as you import the clients and services, you have the new ids to update with. WHMCS manages to do this with their importers from other billing platforms, so the concept must simple if they pulled it off

There is a lot going on behind the scenes, take a look at the code. Also, max_execution_time is not a security concern, although leaving the setting high on a production server can cause issues if a script doesn't stop executing. Making the exception for a script like this is exactly the right time to do it. Since you are convinced that this script can be better and faster, why not put your skills to use and help Cody improve the importer if you know it can be done more efficiently. I'm sure he'd be grateful, I know I'd love to not take 2 hours on an import only to have it fail and have to try it again.

You need to change your php settings, specifically max_execution_time, set it to a crazy large number. Mine takes over 2 hours to complete, I am writing a very long query to prune my WHMCS database so that I can have a smaller test import using real client data. Deleting all but 2,000 clients. Writing this query really has me going WTF??? Why do some WHMCS tables use clientid while others use userid? This is such a cluster...

This is not true, the refundid is the id of the original transaction. When you refund a payment either partially or full in WHMCS, it is always tied to a payment transaction. I don't know if it will let you issue a refund on an unpaid invoice (not paid in full). I've only ever issued a refund if a customer needed an addon removed after paying the invoice, or if there was a double payment on the invoice. Because I believe that you cannot refund on an unpaid invoice, this may be true. The problem is obviously that a refunded invoice could be considered cancelled (voided) or paid in full since the original payment paid the invoice but part was refunded for whatever reason. It's messy yes, but if you don't handle refunded invoices and I import my clients, a bunch of them are going to get late notices and I'm going to be very confused. Any thoughts on my other issues? Why is the importer redirecting when completed?

FYI, mine is line 78. I know this wasn't directed to me but I'll see if it makes mine work better with showing errors.

Finished importing again, still no luck with any kind of an error, just a redirect back to this page with no status: Still missing the previously mentioned items.

Take a look at tblaccounts. The refundid is the id of the original transaction id that was refunded. The amountout is the amount of the refund. This means that an invoice can be paid in full by one transaction which is what you would expect, but another transaction could be a partial refund. This happens all the time, an invoice for $100 could be paid by one transaction but then a refund of $25.00 was issued on that original payment and refunded back to their credit card or paypal account. This could be for any reason, but the issue here is that the invoice is considered paid in full but shows a status of refunded. WHMCS uses refunded for a status whether the invoice is 100% refunded or just partially refunded. You're going to have to look at transactions that have a refundid and process them differently. Same with the invoices they are tied to. Here's a potential and rough work flow. Is transaction a refund? What is the invoice amount due Is this a full refund? If yes, void the invoice If no, the invoice is paid

This is going to be complicated. I'll give you my thoughts in a bit. If you've ever used WHMCS, you know this not to be true.

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.

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.

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...

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.

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.

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.

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.

Like I said, it redirects to the import manager screen and no longer reports success or failure. As for support departments:

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.

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.

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.

* DING DING * Round 5? Starting the import again with 3.0.5 and Migrator b5.

That is part of it. The other issue was the way products were being pulled over, the 8 or 10 different products for each TLD. I also had issues with the import on modules: http://www.blesta.com/forums/index.php?/topic/960-whmcs-migrator-beta-updated-2013-10-25/page-5#entry10409 I also had the pricing issues. I wasn't aware of any new releases from Cody that addressed my issues specifically.