October 29, 2019 at 12:50 pm
As discussed in another thread I am in the process of switching from Win 7 to Win 10 on a box that currently runs SQL Server 2008. I understand that SQL Server 2008 needs to be upgraded to a newer version as it is not supported in Windows 10 and is not being updated.
SQL Server 2017 is not supported in Windows 7. In the other thread mentioned above we discussed a straight hop from SQL Server 2008 to SQL Server 2017 by exporting everything, migrating credentials etc.
I wondered if the following path might be easier:
I recognise that everything should be backed up and preserved prior to the steps above in case anything goes wrong. However if nothing does go wrong, would credentials be automatically moved if I follow these steps? Or would one of the steps result in loss of credentials, authentication or something else that would result in me having to restore databases and users etc. after step 3?
October 29, 2019 at 1:30 pm
Seems like a lot of work.
Presumably you have considered:
?
If you haven't even tried to resolve your issue, please don't expect the hard-working volunteers here to waste their time providing links to answers which you could easily have found yourself.
October 29, 2019 at 7:38 pm
As far as I know, that should work as long as you are not wiping the disk when you go from 7 to 10. If you wipe the disk, you will want to make sure you have backups of the system databases as well as the user databases for when you do that upgrade so you don't lose things like logins.
When you upgrade to 2014 you would want to do a bunch of sanity checks to make sure the data is good (checkdb) and performance didn't tank (run several stored procedures and select queries and make sure that performance seems decent).
System databases are the only ones that are a pain in the behind to work with a restore on, but also the most interesting to learn how to do that restore. My opinion, I don't like doing more than 2 major version upgrades in one go and going from 2008 to 2017 is a pretty big jump and I'd be nervous about some odd incompatibility issues or weird performance issues. The problem with doing the small hops is it is a lot more time consuming to do.
The above is all just my opinion on what you should do.
As with all advice you find on a random internet forum - you shouldn't blindly follow it. Always test on a test server to see if there is negative side effects before making changes to live!
I recommend you NEVER run "random code" you found online on any system you care about UNLESS you understand and can verify the code OR you don't care if the code trashes your system.
October 31, 2019 at 3:33 pm
As an update, I've now done the SQL Server 2008->2014 upgrade in Windows 7 and then the Windows 7 to Windows 10 upgrade (keeping files and apps). All went well, SQL Server 2014 is available in Windows 10, my credentials etc. still work and I didn't need to restore databases; they were preserved during the upgrade because I used the 'keep files and apps' option in the Windows 10 upgrade process. There was a little trouble with an unrelated driver during the Windows 10 upgrade process which I tracked down using setupdiag.exe, disabled the (unneeded) e-sata controller at the root of the issue and then the upgrade worked.
I'll probably now just wait for SQL Server 2019 to come out and upgrade to that from 2014 instead of going from 2014 to 2017 like I had planned originally.
October 31, 2019 at 6:55 pm
Thanks for the update! And I am glad to hear it went off smoothly!
Some post-upgrade steps (on 2014) that you may want to check are:
1 - update statistics
2 - check and change compatibility level if neccessary
3 - fresh backup
I would recommend doing statistics updates on a schedule if this is something that is going to have changing data, and changing the compatibility level is just to make sure you are actually using the new tricks that 2014 offers.
The above is all just my opinion on what you should do.
As with all advice you find on a random internet forum - you shouldn't blindly follow it. Always test on a test server to see if there is negative side effects before making changes to live!
I recommend you NEVER run "random code" you found online on any system you care about UNLESS you understand and can verify the code OR you don't care if the code trashes your system.
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply