Why does Epicor support still rely on ftp?

Does anybody else feel frustrated about support’s insistence on only using FTP to accept uploaded databases? For anyone who has been through the upgrade services program, the database packer/cloud transfer tool are much much quicker and simpler to use, plus they are actually secure unlike archaic ftp technology.

Until recently, when support would ask for the database, they would send the ftp instructions but ultimately accept the database uploaded through the database packer “send to support” function which uploads the database. But now they are taking a hardline and insisting they will not work on the case unless the database is uploaded to their ftp site.

While I can understand support is frustrated at the shortcomings of their own internal systems (they have not done the work to seamlessly integrate with the cloud transfer tool, despite it being in production since 2016), meaning more work on their end to load the database from the cloud transfer tool than from the ftp site. However its clearly possible for this integration work to be done - the cloud operations team loads databases from the cloud transfer tool via script and won’t accept them any other way.

I can’t believe I am the only person who objects to the use of ftp?

3 Likes

:raised_hand:

You are not the only person. Hopefully it’s only sftp or ftps and not unencrypted ftp. Also, I would be really wary of asking for company data in today’s litigious data privacy world.

I would much prefer a process where the customer creates a cloned environment and grants access for a limited window of time much like Microsoft does.

2 Likes

Glad its not just me! What do you think would convince them to change their position? I think it is sftp but that’s still nowhere as secure as the cloud transfer tool.

A multi-million dollar judgement for a data breach? An ginormous increase in their cyber-insurance policy?

I do respect Epicor’s separation between the cloud team and the rest of the company though. And maybe that’s what is driving this. :person_shrugging: If support had an image of every patch (which they generally do, or a major version that they patch as needed), they could easily send a customer a script with an ARM/Bicep template to create an environment. Then pass it a reference to the SQL backup file and restore it. Finally, grant Support access to that environment with all the restrictions, logging, etc to cover Epicor’s :peach:.

I like to submit reproduceable bugs in the Educational database when I can and take the whole data concerns out of the picture when possible.

Right, but when the problem IS the data (we have an orphan record I am trying to get cleaned up - has probably been there since E9), then they really can’t do anything without the database.

I’ve asked them to delete previous copies before, but when working on another case I still saw it on there. I haven’t had to do this with my new place of employment, but I wonder what the T&C are for this process…(read as “too lazy to look it up right now”)