Down grading ss2012 Standard implementation and reinstalling ss2012 Developer Edition.
Installation keeps failing due to the SSISDB .mdf/.ldf files than rename in the same folder location from previous installation. Unable to delete or move these files although a local admin on the server. Throws error below when installing. Completes install however the SQL Engine and Reporting Services do not install.
Updating permission setting for file 'C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\DATA\SSISDB.ldf failed
Backed up all DBs, saved Master Key, all best practice preparation steps for a down grade completed. Any ides?
fwiw that's not really a downgrade: Developer Edition has all the same features as Enterprise. Only the licensing differs (can't use Dev edition for production)
Your error message is refering to the file system, not to any database setting. Ensure that the user (you?) running the install has the correct permissions and that the files are closed when you do it.
Hi and thanks for the response. To update the post.
"down-grade" from a license perspective as on clients site where they have mistakenly installed ENT/STD editions on non prod servers.
Your quite right the issue was attributed to the OS and not SQL Server. Client withheld the service accounts passwords in favour of my using the login they provided me which had local admin on the OS. Turn's out the account required permission to "log on as a service" which would had enabled me to copy/rename/delete the SSISDB .mdf/.ldf which was failing the (re) install .
My workaround was to explicitly go the properties of every DB, Advance, and assign rights to my login before I could (1) complete remove the old SSISDB files and complete installation and (2) once installed Attach the user DBs.
Be warned engineer's, ensure your client provides you adequate permission before agreeing to weekend work with strict Monday morning deadlines. 
Just because a server is labeled as DEV or QA or TEST (or anything else we might consider non-production) do not mistake this as a non-production system according to Microsoft licensing.
If the users accessing this system do not have a developers license and/or any end users access the system for any reason (e.g. QA/UAT environment) then running developer's edition on that server could be in violation of the licensing agreement.
I would recommend validating your exact scenario with Microsoft.
Thanks for bringing up those valid points.
In this case already completed the verification phase, ratified by the companies reseller. Highlights a common problem within the industry itself. Vendors/resellers opaque about the actual criteria of what is defined as production data, scaring companies into over provisioning licenses.
Normally one of my first tasks when at a new client, audit their SQL Server implementation and advise what they didn't need to install, more often than what they should....
Actually if you have just one developer's edition you can deploy it on as many boxes (servers or workstations) as you like. There is no limit. I verified this with the sales team.
What you cannot do, though, is use it to deploy a production workload.
But would you still need x10 CALs if you had x10 Developers accessing the box?
acessing a std/enterprise? yes. Accessing a dev instance, nope.
Great news for Dev installations then.
and soon...run that instance on Linux!