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)
• IE6 => IE7 and FF1.5 => FF2.0 (for javascripts and CSS)

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.