>>The browser is a cost free, simple way of giving users mobile access to data and it its transforming businesses.
>>If the app is a better way and does things that we can't do in the browser, we'll figure that out.
>>So far, there are no compelling pulls in that direction - probably because of naiveté.
>>When we see the light, we'll move.

Agreed. It's not a religious argument. ;-)

FWIW, having moved a certain class of user 100% to browser in the early 2000s, I ran a comparison doing their sophisticated work in the browser app (that they love) versus our new C++ app.

I'm thinking they can hit at least 25% efficiency improvement from the instant snap of the Windows app and user ability to choose and distribute multiple communicating windows persistently across multiple screens to display vast amounts of data that used to need lots of popup dialogs.

You talk about cost: while we standardized on jquery-like UI, we've had to tweak the CSS repeatedly as standards kept changing and the latest Windows 10 update did it again. Meanwhile Windows stuff we deprecated in 2000 got dusted down recently and fires up beautifully on Windows 10 without being touched. The only annoying lapse is that you can't compile straight to x64 because MS didn't include an x64 Commoncontrols ActiveX and useful dlls like sweetpotato are 32-bit only obviously. But why x64 for user apps anyway? The 32 bit version uses less than 100Mb RAM even under heavy load and delivers instant responses. So all we've done is mimic the Metro style and compile. This first customer already has RDS so it's easy enough to deploy it widely- but my pick is that this customer is going to review the cost under Azure and seriously consider it. I wish they would- in 2018 it's cheaper to maintain this stuff ourselves than shepherd customers' ever-younger IT staff. Meanwhile we have other browser apps that ain't broke and will be staying that way indefinitely, same as yours.