Other commenters have mentioned you should figure out why they want to do this, which is important. There could be actual, real legal requirements. There could be internal policies which are, or aren't, flexible. It could just be an IT department protecting its fiefdom.

There are in-between options.

* Tell them that the software is designed to run on your own infrastructure, and while it could be delivered in a form they could run themselves, it would take a lot of extra time or money.

* Offer to run it yourself, but as an entirely separate instance just for them, without the intermingling of other customer data. You'd basically have a parallel setup inside a different AWS account.

* One big reason they might want to run it themselves, is that if your business goes down, they don't experience immediate disruption. It's not uncommon for a code escrow agreement to exist, which means that if your business becomes insolvent, the client gets a copy of your code, and the right to maintain it themselves. Combine this with a separate AWS account running their instance, and give them administrative and billing access to that AWS instance, and you may address their continuity concerns.

* Tell them that you don't support the software on Windows, or Oracle, and that while they can run it on their own setup, they'll have to do it on top of Linux. (If the IT department just tries to routinely absorb everything, this may give them pause)

* Deliver the software as a virtual applicance. (Require a particular hypervisor - for instance, Github is delivered as a VM that only runs on top of VirtualBox or VMWare. The former isn't recommended for production use for performance reasons)

Thanks for the suggestions. Our app uses sensitive data (Customer's name, address, etc., 30k new entries/month) and they don't want that to be leaked. Their biggest concern is accessing the webpage and having that data being served through HTTP (We bought an SSL certificate and all our data goes through HTTPS, but still).

It looks like a mobile app is part of your solution. How are drivers' phones going to access your servers?

I'm really speculating here, but do they want to run the service in a private IP space (inaccessible from the Internet) and have their driver's phones VPN in? If so, maybe you could run a standalone instance of the app in AWS without public IPs, and bridge that to their corporate network using http://aws.amazon.com/vpc/

Bingo! Yesterday we came up with a very similar solution. We'll be proposing it as an alternative today, we'll see how it goes. What we'll do is VPN the DB connection to their private servers, and manage the Redis/Mongo (non-sensitive) in the standard AWS stack. We already do it that way now, but using an internal DB server in AWS.

Fortunately, they haven't made any comments on the mobile app connection/data storage yet :) . That's a bigger problem I guess, since we need the phone's internal DB to store some data (it needs to work offline). I mean, they are secure enough, but given our client's previous records I don't think they'll share our opinion.

Understand why they want what they want. It could be deeply entrenched in data governance / IT Security. Once you understand why they want what they want, ask what the process would be for changing the policies / recommendation?

It's not about having a better solution, cloud v. internal servers. It's about understanding the business requirements that make them recommend their servers. Then, understand how they make their decisions and see if you can use those channels to persuade them.

You're absolutely right. We're in that process now but I wanted to hear some concrete opinions or alternatives we could offer.

Excellent answer.

Congrats!

You may have already lost this battle by allowing it to be an option. If you really didn't want to do it you should have either:

0. Not offered it as an option 1. Priced the option off the table (i.e. 10-100 x the next closest option)

High pricing either makes the customer not consider the option or is enough money to totally make it worth your while.

Also:

1. Why do you not want to do it? 2. Why do they want to do it that way?

What alternatives have you laid on the table that satisfy the majority of their needs within their budgetary constraints?

> 0. Not offered it as an option 1. Priced the option off the table (i.e. 10-100 x the next closest option)

Really overpricing it is something I didn't think of. We were just thinking of charging the man-hours and a little extra.

> 1. Why do you not want to do it?

Costs of maintenance, portability issues, etc.

> 2. Why do they want to do it that way?

Privacy concerns.

Oh, and, thanks!

Find their biggest objection and their primary decision maker. You mentioned in a acomment security is a concern for them. Argue that using amazon is far more secure than their system (which is likely true). See aws compliance here: http://aws.amazon.com/compliance/

Excellent resource, thanks!

GitHub's most expensive hosted plan is $200/mo with unlimited users. Their self-hosted version is a minimum of $20k/yr ($1666/mo) for 20 users.

They also ship GitHub Enterprise as VM "appliance" image, which is probably the only sane way to package up a system that wasn't originally designed to be run in many environments.

Did you ask why they want to host on their servers?

Usually this is a security/privacy concern.

Exactly, that is the issue here.

tell them the cost of your support package?