For all customers questions arise sooner or later about technology upgrades and changes in platforms, languages and APIs. When should it be done? To what technologies? How to handle the transformation? The questions can not be answered here, because it is a question which leads to different answers in different organizations, projects and teams.
One criterion to think about is standardization. In a lot of cases it is best to wait until a technology has reached a certain kind of standardization. The technology is supported then for a longer time without to much change and some backward compatibility. Some basic behavior and interfaces are quite fixed and are not to be expected to change to much in a short time. This is especially important for smaller organizations which can not handle too much change in a too short time range due to resource deficits. It can be more safe to wait until some standardization documents are out and some bigger players in the market have fixed some details and have committed their interest. The investment in a new technology is more safe afterwards.
A good example are OpenGL and OpenCL. OpenGL is a long time out now and is one of the standards for 3D graphics programming. It is expected, that OpenGL will evolve over time, but it is not to be expected to be disappearing in a short time range without any notification. To much companies and organizations are involved in the standardization process. One of the next big things might be OpenCL. With companies like Apple, Intel, AMD (, ATI), nVidia,… the list of supporters is long and technologies are evolving.
A wise decision to a new technology leads automatically to a competitive advantage due to the fact that competitors on the market might not have migrated, yet. The own organization’s products are faster, more accurate, more flexible. more easy to use or what so ever. One only has to be aware not to create an incompatible product.
With a change to a new technology one also should think about to put a kind of fall-back mechanism in which might change internally to a former implementation of the functionality to enable customers which might not have the latest technology available to use the own products. For OpenCL as an example, this might lead to a check for OpenCL compatible hardware and if not present to a fall-back to the older implementations. This slows down the application to a former level, but the customer is able to use the product which is more important than having the best performance.
These are just some thoughts on technology migration which came to my mind during some discussions with customers and managers. One should take care about the decision about new technologies. Not to change is not an option and it is also not an option to change the technologies every time there is something new at the market. One has to find the own speed and the right time for one self.