Migration to Windows Azure

Migration to Windows Azure makes sense for an application handling large volumes of data or consuming substantial CPU resources

Quite a few of our clients who plan to have their legacy systems migrated to .NET platform consider Windows Azure as an option. To help clients with making this decision, we list key points for consideration, both from business and technology aspects.

Business Considerations

Migration to Windows Azure makes sense for an application handling large volumes of data or consuming substantial CPU resources. It might be a website serving large number of visitors or a data processing engine crunching terabytes of data. A good example is a scientific application performing large-scale simulations. Once moved to the cloud, the system becomes not only highly scalable, but more importantly, scalable on demand. No additional onsite hardware deployment is needed, no extra server configurations by a hosting provider are necessary. Maintaining redundant hardware to handle occasional peak loads is no longer required.

Cloud computing doesn’t work equally well in all cases. In particular, moving a line-of-business application tightly integrated with the local IT infrastructure (Active Directory, mail servers, local data storages, etc.) to the cloud is technically complicated and exposes the risk of communication link failure.

We won’t discuss generic risks associated with cloud computing as they are well known. However, one typically overlooked risk requires mentioning: data backup and restoring. Windows Azure ensures the physical integrity of the data but it doesn’t provide any built-in tools to create and restore a snapshot of the data at a later time in case of logical inconsistency. Such functionality, if required, should be implemented inside the application.

In some industries, such as banking or military services, using clouds is not allowed by the legislation which demands that the data be physically stored in a specific, properly secured site.

Technology Considerations


Developing for Windows Azure is similar to traditional .NET application development. Microsoft .NET is a mainstream, well-documented technology with a vast pool of service providers and software engineers available at a fair price.


Below are a few recommendations to take into consideration when developing your Windows Azure application.

  • Separate presentation, business logic and data layers
    Even though multi-layer architecture is a well-known design pattern we’ll highlight the benefits of using it in a cloud application. For Windows Azure it’s important to isolate business entities from the way they are stored. Despite certain data mapping overhead, this approach allows to keep the application on premise or to move it to an alternative cloud platform with minimal efforts by switching to an alternative data layer implementation. Such isolation helps to mitigate a risk of a vendor lock-in.
  • Design storage structure and data access routines early on
    It’s best not to put all the data types into Azure storage which is intended for really large volumes of data. Keep data of limited size in SQL databases to benefit from schemas, indexes, foreign keys, stored procedures and many other advantages of relational databases which help to keep the data consistent. Use BLOB or Table storage for data you expect to grow over time to millions of records and above. Remember that Table storage requires exactly two fields to form a primary key and doesn’t support indexes, so the primary key should be carefully designed to guarantee a quick access to data. In addition, a single query to Table storage returns at most 1000 rows; to fetch the remaining rows one should repeat the query with a continuation token. The same applies to bulk record deletion: each row to be deleted should be retrieved first. All those restrictions should be considered when designing the architecture (for example, pagination of the results on a web page requires keeping a continuation token somewhere).
  • Design a concurrent system
    Cloud applications are concurrent by design because there’re always at least two instances of each application running. Windows Azure guaranties transactional and concurrent access to the cloud data storage via a timestamp field, a proper version of which has to be provided for successful record update; otherwise an error is returned. A Cloud application should be designed to properly handle such errors. Another important aspect of concurrency is synchronization between application instances which is typically required to perform a single action, for example sending an email. Such a mechanism is not provided by the platform and has to be supported by the application. An SQL database can be a convenient way to implement it.
  • Carefully plan deployment & upgrade scenarios
    Deployment of a new application version can be a complex task which depends on the nature of the changes and may require shutting down the system. This typically happens when data storage schema is changed in such a way that it requires to shut down the application, to manually upgrade the storage schema, deploy the new version of application, and then start the system again. As mentioned above, Windows Azure doesn’t offer a “backup” option, so restoring the original state of the storage after a wrong upgrade would be a rather painful if at all possible procedure. In the meantime, minor upgrades can be easily done using a Staging environment supported by Windows Azure.

Other Considerations

We’d like to mention two more points. First, don’t assume that Windows Azure hosting environment has any preinstalled software. It’s a bare operating system. Any functionality, usually supported by preinstalled software, should be instead implemented within the application hosted on Windows Azure. A typical example is sending an email: unlike on-premises applications which can simply queue messages to a local (preinstalled) mail service, a cloud application should connect to an external mail server and take care of connectivity issues by queuing messages somewhere.

The second point to remember is that debugging a cloud application is rather hard if at all possible. Therefore, the application should emit and store enough debugging information to allow for discovering and tracing problems in the code.

See also: