Continous migration in software development
New (and soon to be deprecated) technologies are just flowing in the Software industry. Some people pointed out that you can’t stop improving your product just to keep the pace with the release flow (that’s the fire and motion theory). Yet, being an ISV, your options are quite limited. You have to rely on the latest (yet stable) technologies in order to maintain a highly competitive productivity.
Rewriting from scratch your application to support the latest Foo.NET release is a bad idea; no question asked. Yet, it must be taken into account that
getting people interested (worse, training them) on deprecated technologies (let’s say Classic ASP) is both hard and depressing.
not beneficing from the latest tools means lower productivity. Ex: Classic ASP => ASP.Net 1.1 => ASP.Net 2.0, each new version being a huge time-saver compared to the previous one).
Lokad.com has been existing for less than a year and, we have already performed quite a lot of migrations.
SQL Server 2000 => SQL Server 2005
ASP.Net website => ASP.Net web application
No AJAX => ATLAS (betas) => ASP.Net AJAX Extensions
NAnt => MsBuild (when the MsBuild Community Tasks have been released)
VS 2005 Setup Project => WiX 2.0
Command Line => PowerShell (for our command-line tools)
Among the next planned migrations
Visual Studio 2005 => Orcas
WiX 2.0 => WiX 3.0
Inline SQL in C# => LINQ
NDoc => SandCastle
NuSoap => PHP5 Web Services
osCommerce 2.2 => osC 3.0 (currently alpha) => osC 3.1 (for the plugin framework)
Our processes at Lokad involve continuous migrations toward new technologies. Upgrading take time and efforts, yet this process seems quite necessary to maintain optimal development conditions.