In-Place Upgrade or Migration

  • Comments posted to this topic are about the item In-Place Upgrade or Migration

  • I would in most cases choose to migrate to another server.
    During the years there are always new insights how to best configure the system, maybe you want to rearrange drives to make it a more logical setup.
    And foremost I've had too many issues with in place upgrades creating all kinds of errors.

    Another great factor is that in some cases you can leave the databases on the old system in a read-only state making it possible to let the application run as long as possible.

    Migrating to another server has become a whole lot simpler with the right tools.
    I don't want to advertise anything but the Start-Migration function in the PowerShell dbatools module has really made a difference.

  • Good article. I've done both upgrades and migrations and I favor the migration. In addition to the pros you mentioned if there are new features or functions in the application software using the database, migrating with new hardware and software gives you a training ground for your users to learn the changes before the go live date.

  • I also favor migration.  What we have done to address the issue with applications referencing the server name or even the IP address is to keep the same name and IP address.  I'll set up a server with a new name, do the install and configuration and finally migrate.  Then we take both down and re-name and re-IP the boxes.  The service interruption is marginal to none (if we work off-hours).

  • I've done a few in-place migrations on some virtual machines. Its a lot simpler if the upgrade isn't too big and the OS is aceptable. And the VM snapshot simplifies rollback - not that I've had to use it though.

  • sqlstad - Tuesday, February 28, 2017 3:27 AM

    I would in most cases choose to migrate to another server.
    During the years there are always new insights how to best configure the system, maybe you want to rearrange drives to make it a more logical setup.
    And foremost I've had too many issues with in place upgrades creating all kinds of errors.

    Another great factor is that in some cases you can leave the databases on the old system in a read-only state making it possible to let the application run as long as possible.

    Migrating to another server has become a whole lot simpler with the right tools.
    I don't want to advertise anything but the Start-Migration function in the PowerShell dbatools module has really made a difference.

    dbtools are excellent but one might want to clean up some of the residuals rather than migrating everything.
    😎

  • Eirikur Eiriksson - Tuesday, February 28, 2017 12:29 PM

    sqlstad - Tuesday, February 28, 2017 3:27 AM

    I would in most cases choose to migrate to another server.
    During the years there are always new insights how to best configure the system, maybe you want to rearrange drives to make it a more logical setup.
    And foremost I've had too many issues with in place upgrades creating all kinds of errors.

    Another great factor is that in some cases you can leave the databases on the old system in a read-only state making it possible to let the application run as long as possible.

    Migrating to another server has become a whole lot simpler with the right tools.
    I don't want to advertise anything but the Start-Migration function in the PowerShell dbatools module has really made a difference.

    dbtools are excellent but one might want to clean up some of the residuals rather than migrating everything.
    😎

    The Start-SqlMigration is just a wrapper function for most of the Copy-____ functions. So you can piecemeal what you want to copy and what you want to leave. I rarely use the start functions to migrate customer servers for just a purpose/reason.

    Shawn Melton
    Twitter: @wsmelton
    Blog: wsmelton.github.com
    Github: wsmelton

Viewing 7 posts - 1 through 6 (of 6 total)

You must be logged in to reply to this topic. Login to reply