Chapter 10:​ Moving Your Data to the Cloud

I feel several of the chapters in this book, while important, can be viewed as peripheral to migration. This chapter however is key. There are a great many tools that can be used to migrate to the cloud. Your choice is probably dictated by your previous experience (I know I tend to automatically go to DMA and the Migrate menu item in SSMS). This chapter discusses the factors to consider when moving data, and the pros and cons of the various tools. No step-by-step walkthroughs are given, since the authors believe the screenshots etc will become out of date too soon. 

The chapter opens with a look at which service you need, e.g. Azure SQL Databases. Some factors (e.g. use of SQL Agent) can remove some of your choices. Some tools allow migration while online.

There’s a helpful, and possibly neglected, section on some factors that affect your migration, namely internet throughput (affects migration duration) and internet connections (affects security). There’s a useful table of internet speed, amount of data to migrate, and the expected migration duration. 

Next, core to this chapter (and perhaps the whole book), is a section on the various migration tools. These include:

• Database Migration Service (DMS) – most popular, for a wide range of databases, allows migration at scale, basic (free) and premium (has cost)
• Backup and Restore – If migrating to Azure SQL VM, you can use the native SQL backup and restore commands
• BACPAC – you can’t restore a native backup to a PaaS database but you can create a BACPAC file of the on-premise database, and then import this into Azure
• Physical transfer – for very large databases, where cost and duration of migration are prohibitively high, can ship Azure Data Box to Microsoft who can then load it

Other tools exist, and Microsoft might be able to offer some other options for your circumstances. The importance of testing is highlighted, since this can affect the approach, downtime, and quirks.

This was a very useful chapter, with lots of detail. In many ways, I expected the book to be an extension of this chapter.

Again, in some places, related information is scattered in different places, this occurs both in this chapter and across the book, and important information is given in passing. It might have been better to have an overview of technology (e.g. IaaS, serverless, etc) in one place.

Chapter 11:​ Data Validation Testing

For smaller projects there’s often the temptation to migrate and then fix any problems afterwards. Bigger projects need more planning, especially concerning data validation. This is typically done by DBAs working together with Subject Matter Experts (SMEs). 

Validation requires a deep understanding of data and applications. SMEs will usually know if a result looks right. There are many ways to validate data. Manual validation is typically time consuming and tedious. Manual validation with sampling, usually provides greater coverage for the available resources, where you perhaps look at the most important customers. Automated validation, using tools like PowerShell and T-SQL typically provide repeatability and reliability. It’s important to pay attention to any migration report output.

It's important to validate data to ensure no unexpected changes have been introduced by the migration. This includes any bugs in SQL Server, and functionality changes (e.g. the Cardinality Estimator). The use of the Compatibility Level can help reduce the impact of these.

The importance of a scope definition documents is noted. As well as useful for future analysis, the document should contain a summary of the tests to perform, who will do the testing, roles, deadlines, together with any success criteria. Simple tests can compare reports on the on-premise and cloud systems, also table row counts, and statistical and hash checks on important columns. There’s some useful code for calculating the average and standard deviation for given columns. 

The chapter ends with a request to ensure each output has its performance recorded, else it can be easy to miss a decrease in performance, which itself can cause user of the new system to take a negative view of the migration.

This is a useful chapter, with lots of valid points. It’s important to perform whatever test to ensure the migration hasn’t introduced any problems.

Chapter 12:​ Postmigration Tasks

It’s very easy to declare a successful migration too early. There are always new projects that demand attention, almost as soon as the success emails are sent out. However, it’s important to look at postmigration tasks that still need attention, these include:

• decommissioning legacy resources – there’s a useful list of steps to remove the old system
• validation and optimization – experience shows you’re unlikely to catch all problems during your testing, so allow some time for this after the migration
• performance issues – again, the project emphasis is often on ensuring the results are the same. Performance problems often occur postmigration, and need attention

This was a useful chapter, for highlighting that a project may still need attention after the migration step.

Chapter 13:​ Post Mortem

Much of this chapter has an overlap with the similar stages in Scrum or Agile project methodologies. Here, we look at everything, from the start to the end of the project, to see what went well, what didn’t go well, and how things can be improved for future projects.

First, the benefits of a post mortem are discussed. It’s important to thank the people that did the work, and to learn from mistakes in the hope that future projects can be improved. It’s noted that you get out of it what you put in. It also gives the project closure. Details of the process are highlighted, typically a questionnaire is used, staff will need time to formulate their answers. Items discussed include: a moderator, plan workshop, structure workshop, set up rules guidelines, and takeaways.

There are some useful questions offered, these are typically subjective, inviting staff to provide more detailed answers. If there are many staff, common themes in the replies can be summarized. It’s important to have guaranteed anonymity – so people can answer without fear of repercussions, also quite voice has same impact as loud ones. Where possible, the questions should also ask for any solutions to any problems.

For the post mortem workshop, a moderator should be used to ensure the discussions stay on track and don’t become personal attacks. Lastly, it’s suggested various ways to show appreciation are given, including: a personal thank you note, lunch, gift, day off, money, promotion etc.

This was an interesting chapter. Too often, after a successfully project, staff move onto the next project without having a post mortem. A chance to discuss problems can help prevent future one. As with many of this book’s chapters, this is an important topic, but is it needed in a migration book?

Conclusion
This book aims to give you a holistic approach to migrating on-premise databases to Azure, and generally succeeds. It is mostly easy to read, but some areas (e.g. security, networking) will probably need input from other areas. There are good connections between the chapters, helpful website links for
further information, good diagrams to support the discussions, some useful template SQL code, plenty of incidental tips and advice, and helpful chapter summaries.

Generally, the book is conversational in nature, this may be OK, since many people learn from stories. Cliches abound, which is perhaps to be expected with older IT people. Sometimes, terms are introduced without adequate definitions (they are often given later), this may be ok, since the book assumes some experience.

As a general text for migrating systems to the cloud, containing several quite detailed areas, I’m not sure how appropriate all the chapters are for all the different types of the purported readers (i.e. IT leadership, IT decision makers, project owners, managers, enterprise and application architects, enterprise DBAs, and consultants). For example, I can’t imagine many PMs being enamoured of learning about the details underlying networking.

If you want to know how to run a migration project, from start to finish, then this book will give you plenty of guidance. If you’re only interested in the steps around migration itself, then you may feel this book has too many unnecessary chapters. I feel there is room for another book focusing solely on technical aspects of migration, that has step-by-step walkthroughs. Yes, the screenshots might become out of date, but the underlying process would be illustrated.

To keep up with our coverage of books for programmers, follow @bookwatchiprog on Twitter or subscribe to I Programmer's Books RSS feed for each day's new addition to Book Watch and for new reviews.