The Intel 8086 is in turn backward-compatible at the assembly language level to the 8-bit Intel 8080 and 8008. Intel provided a tool to machine-translate 8080 ASM source code into 8086. For the most part it was fully automatic, but there were a few instructions that needed manual intervention. Even so, it made it cheap to port 8080 software to 8086, providing instant software for 8086 and 8088.
The automatically-translated code used 8-bit registers and didn't take full advantage of 8086's 16-bit instructions, so you didn't get any performance improvement. If memory serves, the new 4.77 MHz IBM PC ran early software slower than an 8 MHz Z-80 computer in spite of the PC's 16-bit 8088 processor.
I used to help manage compatibility at Symbian (the smarphone operating system company), and I agree it's a constant dilemma. If you want your customers to buy your latest product, they need to know how much time and effort will be involved in migrating their old applications, hardware, working methods and so on. It's no good just saying "we don't support the old product any more" and expecting customers to stay loyal ([cough] Windows XP).
It's a dilemma for customers as well. They need a migration path - information about how and when to modify anything that relies on compatibililty with your product so they can assess what will continue to work after an upgrade and what won't, what the costs and timescales will be and weigh those costs against the benefits of upgrading. If you spell that out for customers, they will tell you how much effort to spend on compatibility. As you say above, "Some of the best ideas come from our customers."
You may be suprised to find some old (and even new) features are almost completely unused and hence there's no point spending time and money supporting them. They should be deprecated and eventually removed. On the other hand, you may be pleasantly surprised to find that some original features you thought were obsolete are actually still heavily used (even though better alternatives exist) but no-one complains because they "just work".
If breaking compatibility is more in your interest than your customer's, it may be worth making a migration tool or offering free assistance if an upgrade goes wrong.
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Are the design challenges the same as with embedded systems, but with a little developer- and IT-skills added in? What do engineers need to know? Rick Merritt talks with two experts about the tools and best options for designing IoT devices in 2016. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.