Sage 50 Quantum in Hyper-V VM
-
Sage has been a joke for years. Old news, anyone whose ever dealt with them knows this in and out.
-
@Breffni-Potter said in Sage 50 Quantum in Hyper-V VM:
Sage has been a joke for years. Old news, anyone whose ever dealt with them knows this in and out.
I feel like they were considered pretty silly back around 2000 when we decided not to look at them further. Always makes me wonder... what process leads companies to have bought into software like this in the first place?
-
Pick one:
Accountants who only know one software package
Accountants who are mostly resistant to change/new ways
Accountants who are risk averse/narrow focused
Accountants who get a commission from Sage for recommending it to their clients
Accountants who say "It is the software everybody uses"And this is why I know how to do my own books.
-
@Breffni-Potter said in Sage 50 Quantum in Hyper-V VM:
Accountants who are risk averse/narrow focused
More like risk confused. Risk aversion would get them onto an enterprise platform and trusting their business and tech advisers immediately. Using non-production, unsupported products is "embracing risk", nearly to the point of "for the fun of it."
-
@Breffni-Potter said in Sage 50 Quantum in Hyper-V VM:
Accountants who get a commission from Sage for recommending it to their clients
Yeah... the old vendor advice problem.
-
@scottalanmiller said in Sage 50 Quantum in Hyper-V VM:
@Breffni-Potter said in Sage 50 Quantum in Hyper-V VM:
Accountants who are risk averse/narrow focused
More like risk confused. Risk aversion would get....
...Them to advise their clients to invest wisely in growing their business rather than stagnating in a turtle shell protection mode.
That annoys me more than the choice of software when I see that happening.
-
@EddieJennings said in Sage 50 Quantum in Hyper-V VM:
Officially tested in QA
Support personnel trained on its useMy perspective (Disclaimer I work for a software company and deal with engineering and PM for support statements almost daily).
Once you commit to support something your on the hook to isolate all faults, and jointly work with the other parties involved until it's fixed.
As one example we certified a RAID controller for use with our platform. That raid controller had a bug. Was it our code's problem? No. Did customers call us and blame us and expect us to drive a solution? Sure.
We used our engineers and our joint support agreement with said hardware vendor to work for weeks around the clock (engineering time isn't cheap) and drive a solution. If you add up all the GSS hours, engineering hours, and project management hours spent dealing with lifecycle for a single raid controller vendor it has cost us millions I'm sure in 2016.
Sage is saying that they don't run Hyper-V in QA for this app. (Running Hyper-V would include not just running Hyper-V on a box and calling it good, but regression testing against Service Packs, Hyper-V guest tools updates, and typically N-1 releases of the major product so they would need 2012R2 tested as well as 2016. For all these variations they would need to dedicated half a dozen servers at a minimum. They would need to extend their automation tools that are doing QE deployments to work with Hyper-V. Considering I've seen dozens of Cloud Management and orchestration products not support Hyper-V. If they don't have a cloud management product in place then they might have to write raw API and PowerCLI calls to do the orchisration for the testing on Hyper-V and KVM and Xen and other platforms. The could easily require hiring 1-2 more FTE's just to much with this and maintaining it.
Sage has a lot of products like this with relatively small market share. Given the choice of them spending millions on testing and providing a support statement for Hyper-V/Xen/KVM and shifting engineering resources to QE and escalation for these platforms, I suspect most of their customers would be annoyed if their roadmap was killed just to maintain steady sate for these other platforms.
I guess what I'm getting at here is that Issuing a support statement is a INCREDIBLY not free thing to do.
I worked with Sage in the past to deploy their stuff on VMware. Once I told them what I was doing and what type of storage etc I was deploying they generally said "yah that sounds fine"
Here is an example of their support statement on Virtualization.
https://support.na.sage.com/selfservice/viewContent.do?externalId=54620&sliceId=1
-
@John-Nicholson but they choose to test on physical. They could have picked one virtual to use instead. Your theory only works if what they did test was an acceptable production scenario.
-
@scottalanmiller said in Sage 50 Quantum in Hyper-V VM:
@John-Nicholson but they choose to test on physical. They could have picked one virtual to use instead. Your theory only works if what they did test was an acceptable production scenario.
Exactly. Nobody runs software on physical computers anymore, and haven't for a very long time.
They may as well be supporting Windows Server 2000 and 2003 if they are testing only physical servers.
They aren't supporting their software in production scenarios, because nobody runs software on physical servers in production. So when they are ready to make their software production-ready, it will be the other way around.
-
@Tim_G said in Sage 50 Quantum in Hyper-V VM:
So when they are ready to make their software production-ready, it will be the other way around.
Exactly. Like if they ONLY supported VMware or ONLY supported Hyper-V or ONLY supported Windows we'd understand. Those are all potential production ways to run software. But a physical deployment? This means that they've never tested and don't support ANY production environment.
There is a big gap between having "one tested environment for production" and "not tested or supported for production."
Exact same reason we dropped FogBugz. They only supported non-production platforms.
