locked
Impact and compatibility of .NET application while migrating SQL2000 on wWINDOWS2000 TO SQL2008R2 standard edition on WINDOWS 2008 RRS feed

  • Question

  • Our application is developed on .NET 2.0,C# and sql2000 backend on windows
    2000 server .The SQL server is going to migrate to SQL2008R2 standard edition on windows 2008R2
    1)Does our application require remediation to support this?
    2)If it is required what specific things needs to be modify?
    3)Does our application can support SQL2008R2 standard edition on windows 2008R2?

    Please advice.

    Sunday, June 1, 2014 6:13 PM

Answers

  • From a SQL point of view, assuming your SQL database is currently running on a compatibility level of 80 (eg SQL 2000) then you'll be able to migrate it to SQL 2008 R2 without that having to change, so you shouldn't have any problems from that point of view.

    As far as I'm aware there's nothing inherent about .Net 2 that should cause you any issues, eg it will still run on 2008 R2, but it really depends on what your application does and how it's been written.

    Assuming your Windows Server 2000 installation is 32-bit then you'll be moving from a 32-bit installation to a 64-bit installation, and any components you're using will need to be capable of running on 64-bit. If you're going to have issues (assuming you are using any additional components) then I imagine this is where you're most likely to find them, since not all old 32-bit components work well or at all on 64-bit windows. If you have any 32-bit apps or components that need to be reinstalled then they'll obviously now be installed into \Program Files (x86)\, so if anything has the folder path to their executables hard coded then you could have issues there.

    Realistically for any internally built application it's hard for anyone outside to judge, and your best option is to try the migration in testing and see if everything works fine. Perhaps get everything setup on the new box without pointing people to the new version, test everything works, and then once you've confirmed everything is working as it should you can re-do the migration of your SQL data to refresh it with the latest data before doing the final switch.

    • Marked as answer by Sofiya Li Monday, June 9, 2014 5:51 AM
    Sunday, June 1, 2014 7:59 PM
  • Hi HarshDhami,

    If you want to migrate SQL Server 2000 on Windows 2000 to SQL Server 2008R2, the following requirements apply to all SQL Server 2008 R2 installations, includes .NET Framework 3.5 SP1 and Microsoft Windows Installer 4.5 or a later version. When you make a backup of SQL 2000 database and restore it on SQL Server 2008 R2, you need to change the compatibility mode to 100 in the properties screen. Also you may need to test your SPs and functions after migration.

    In addition, you also need to transfer the logins from the source server to the destination server, your current SQL Server users may be able to log on to the destination server. After you transfer logins and passwords to the destination server, you need to resolve orphaned users.

    For more information, see

    http://support.microsoft.com/kb/314546/en-us

    http://www.mssqltips.com/sqlservertip/1246/migrating-a-sql-server-instance/

    Regards,
    Sofiya Li


    Sofiya Li
    TechNet Community Support

    • Marked as answer by Sofiya Li Monday, June 9, 2014 5:52 AM
    Tuesday, June 3, 2014 6:23 AM
  • When you make a backup of SQL 2000 database and restore it on SQL Server 2008 R2, you need to change the compatibility mode to 100 in the properties screen.

    If you want to make use of the latest 2008 R2 features then yes, but if the aim is to ensure your existing application continues to work (which is what the OP said) then I'd suggest you should leave the compatibility level alone.

    Once in place you can look at testing a copy of the database using the compatibility level of 100 and see if the application continues to work, but there's always a chance that something in how your application is referencing the database uses something that works differently in 2008 R2. That's surely the whole point of having compatibility levels!

    Long term you definitely want to update it though, since you're at the limit of what is supported. If you later upgrade to SQL 2012 then the compatibility level would have to increase at a minimum to 2005.

    • Marked as answer by Sofiya Li Monday, June 9, 2014 5:51 AM
    Tuesday, June 3, 2014 6:41 AM

All replies

  • Our application is developed on .NET 2.0,C# and sql2000 backend on windows 2000 server .The SQL server is going to migrate to SQL2008R2 standard edition on windows 2008R2
    1)Does our application require remediation to support this?
    2)If it is required what specific things needs to be modify?
    3)Does our application can support SQL2008R2 standard edition on windows 2008R2?

    Please advice.

    • Merged by Sofiya Li Tuesday, June 3, 2014 3:10 AM the same issue
    Sunday, June 1, 2014 6:11 PM
  • From a SQL point of view, assuming your SQL database is currently running on a compatibility level of 80 (eg SQL 2000) then you'll be able to migrate it to SQL 2008 R2 without that having to change, so you shouldn't have any problems from that point of view.

    As far as I'm aware there's nothing inherent about .Net 2 that should cause you any issues, eg it will still run on 2008 R2, but it really depends on what your application does and how it's been written.

    Assuming your Windows Server 2000 installation is 32-bit then you'll be moving from a 32-bit installation to a 64-bit installation, and any components you're using will need to be capable of running on 64-bit. If you're going to have issues (assuming you are using any additional components) then I imagine this is where you're most likely to find them, since not all old 32-bit components work well or at all on 64-bit windows. If you have any 32-bit apps or components that need to be reinstalled then they'll obviously now be installed into \Program Files (x86)\, so if anything has the folder path to their executables hard coded then you could have issues there.

    Realistically for any internally built application it's hard for anyone outside to judge, and your best option is to try the migration in testing and see if everything works fine. Perhaps get everything setup on the new box without pointing people to the new version, test everything works, and then once you've confirmed everything is working as it should you can re-do the migration of your SQL data to refresh it with the latest data before doing the final switch.

    • Marked as answer by Sofiya Li Monday, June 9, 2014 5:51 AM
    Sunday, June 1, 2014 7:59 PM
  • Duplicate post

    duplicate

    Monday, June 2, 2014 1:52 PM
  • Hi HarshDhami,

    If you want to migrate SQL Server 2000 on Windows 2000 to SQL Server 2008R2, the following requirements apply to all SQL Server 2008 R2 installations, includes .NET Framework 3.5 SP1 and Microsoft Windows Installer 4.5 or a later version. When you make a backup of SQL 2000 database and restore it on SQL Server 2008 R2, you need to change the compatibility mode to 100 in the properties screen. Also you may need to test your SPs and functions after migration.

    In addition, you also need to transfer the logins from the source server to the destination server, your current SQL Server users may be able to log on to the destination server. After you transfer logins and passwords to the destination server, you need to resolve orphaned users.

    For more information, see

    http://support.microsoft.com/kb/314546/en-us

    http://www.mssqltips.com/sqlservertip/1246/migrating-a-sql-server-instance/

    Regards,
    Sofiya Li


    Sofiya Li
    TechNet Community Support

    • Marked as answer by Sofiya Li Monday, June 9, 2014 5:52 AM
    Tuesday, June 3, 2014 6:23 AM
  • When you make a backup of SQL 2000 database and restore it on SQL Server 2008 R2, you need to change the compatibility mode to 100 in the properties screen.

    If you want to make use of the latest 2008 R2 features then yes, but if the aim is to ensure your existing application continues to work (which is what the OP said) then I'd suggest you should leave the compatibility level alone.

    Once in place you can look at testing a copy of the database using the compatibility level of 100 and see if the application continues to work, but there's always a chance that something in how your application is referencing the database uses something that works differently in 2008 R2. That's surely the whole point of having compatibility levels!

    Long term you definitely want to update it though, since you're at the limit of what is supported. If you later upgrade to SQL 2012 then the compatibility level would have to increase at a minimum to 2005.

    • Marked as answer by Sofiya Li Monday, June 9, 2014 5:51 AM
    Tuesday, June 3, 2014 6:41 AM