Cloud computing is a relatively new concept in the SQL Server community, so it shouldn’t come as a surprise that there are still a lot of questions surrounding the migration process, data security, and cloud application performance. You can read all you want about how the cloud computing host providers’ environment should work, but if you’re like most DBAs, you need to hear about how it’s working for an actual cloud customer before you begin considering it for your environment. Therefore, SQL Server Magazine is providing you with an inside look at how migrating to the cloud—Microsoft SQL Azure, in particular—went for Quosal, a quote and proposal software provider. We spoke with Stephen Yu, the vice president of development at Quosal, about how the migration process went, how migrating data to the cloud directly affected employees, and the advantages and disadvantages they’ve found to working in SQL Azure.

SQL Server Magazine: Can you give our readers a brief overview of Quosal and your overall experience with the Window Azure platform and SQL Azure?

Stephen Yu: We were founded in 2005 basically to provide a better quoting solution. About 40 percent of the business that’s done in this country is done through quotes and proposals of some kind, the rest being retail or specialty types of business. So we were looking to have this quoting tool that allows people to prepare quotes and proposals easily. My role at the company has been to do the technology research and figure out what [cloud computing] platform we want to adopt, so that’s kind of how we landed on the Microsoft Windows Presentation Foundation of Microsoft .NET, and then SQL Azure as our back-end cloud offering.

We actually were one of the first testers for Azure, so we were able to migrate existing customer data, and [deploy] new customers to SQL Azure, pretty much as soon as SQL Azure was released, which was the beginning of last year. We’ve found it to be a very scalable tool. The main concern for us was whether we were going to do our own hosting around the world or leverage the infrastructure Microsoft had already put in place for their cloud hosting solution. We found that the SQL Azure infrastructure was very effective for us, especially getting into markets in Europe, South Africa, and Australia.

SQL Server Magazine: Can you discuss the migration process and the specific data you migrated to SQL Azure?

Yu: We originally architected Quosal just on a SQL Server back end and SQL Server Express. I think the original version was on SQL Server 2005 and then upgraded to SQL Server 2008. The actual data comprises a couple of different components. The majority of the data in our business objects are things like CRM data from the various CRM packages we integrate to, such as Microsoft Dynamics and Salesforce, so basically customer name, contact information, and the opportunity information on that customer—how hot of a prospect they are, and whether or not they’ll close. The other key piece of information is product data. We have customers across quite a few verticals, but as a general rule most of the product data that comes in to us comes in via real-time XML feeds from various distributors. An example of that would be Tech Data or Ingram Micro in the IT space. They sell parts, say, to Staples or one of our other customers, so we pull in that information from these distributors and populate our database with it. So the kind of information we’re talking about is product description, product brochures in either PDF or image format, such as JPEG. Obviously pictures large and small and thumbnails, and quite a few of the manufacturer marketing descriptions, which reside in Notes text type fields. Each quote varies in size, but you’re probably looking at somewhere between 500KB and 1MB on the high end for a really big quote and on the low end probably 20KB to 100KB of data.

As far as migration goes, the main reason that we were able to migrate to SQL Azure so quickly and effectively is because we built in our own mapping tool. What happens is when the Quosal product is updated, it updates its own schema. One of the big dilemmas we had was, Can we really go to this platform if we have to have our customers manage a remote SQL Server database? And the answer was No. So, because we had this automatic schema updater, we were able to say, “Well, in this case we’re going to use the tool itself to manage this database update.” So really the only time we interact with the Azure database is from basically a web portal or a SQL Server Management Studio perspective during the initial installation. After that, Quosal maintains its own schema updates, checks for the indexes that are needed as it’s running, and recreates them on the fly. Because of that flexibility in our product, we were really able to leverage the transition to SQL Azure and the actual conversion process because it almost looks seamlessly like a SQL Server 2008 database. It probably took about a day or two of coding and/or slight modifications to our connection strings, things like that.