Home Dashboard Directory Help

SSDT BI 2014 backward compatibility for SSIS 2012 by dejann


 as External Help for as External

Sign in
to vote
Type: Suggestion
ID: 944882
Opened: 8/12/2014 5:23:52 PM
Access Restriction: Public


Currently SSDT BI 2014 for Visual Studio 2013 does not support SSIS packages for SQL Server 2012.

Please provide backward compatibility so that developers do not have to use Visual Studio 2012 and 2013 in parallel. Ideally we should be able to use VS 2013 to develop SSIS packages for both SQL 2012 and SQL 2014
Sign in to post a comment.
Posted by Alex Luts on 6/19/2017 at 11:44 PM
What a fail
Posted by TomOakes on 4/11/2016 at 2:29 PM
In case it helps anyone, I just converted our VS2013 project to VS2012 using this blog post as a guide, and it worked very well.


I had to copy-paste rebuild the Script Components, but otherwise everything downgraded very nicely. Thanks to Vanie Castro for that workaround.
Posted by TomOakes on 4/11/2016 at 2:26 PM
This ticket was closed with no comment? Last comment from MS was March 2015 from Leo Shum. Leo what's the story?
Posted by ben1997 on 4/4/2016 at 7:11 PM
I am running into this issue too.
anybody has a workaround?
Posted by EVC on 3/27/2016 at 11:08 AM
Why is this closed? Until all Microsoft products support SQL 2014, support for 2012 should continue. Typical Microsoft.
Posted by M Noreen on 3/15/2016 at 10:44 AM
Has anyone found an update to this? We just had a few developers set up new PCs (Windows 10, VS2015, and of course the most recent SSDT). Yet we are using SQL Serve 2012 and have dozens of packages authored...

Is there a specific version of SSDT that does work, and if so, does someone have a link to that installer?
Posted by enternetic on 3/3/2016 at 4:47 PM
This is closed?!!
Almost two years later, Where is the fix? This is even a issue with VS 2012, the packages throw the version error when running on SQL 2014.
Posted by Kalyan Sutapalli on 2/28/2016 at 1:46 PM
Is there any fix released yet?
Posted by HSalim on 2/26/2016 at 10:41 AM
here is another request to fix this issue.
Posted by George Walters on 10/6/2015 at 1:53 PM
I have a major customer in the Northeast District having serious pain with this issue. We can talk about the impact to the account team as well as support time to help the customer.
Posted by Neill Hansen on 10/6/2015 at 6:47 AM
This is severely impacting our delivery and we were forced now to install a 2012 VM and rebuild our packages. Any news on when this will be rectified?
Posted by ChrisTownsend on 9/11/2015 at 2:24 AM
Why on earth is the BI Suite such a shambles!? Constantly giving us the tools to upgrade only to learn that there is never any backwards compatibility with other products. All my SSIS packages converted to 2013, and look at this I cant actually execute them. Brilliant.
Posted by Stanislav Verjikovskii on 8/19/2015 at 5:42 AM
Come on MS, we are waiting..
Posted by Mustafa S. Ali on 6/29/2015 at 8:45 AM
So when will this be looked into? Either compatibility should be provided as identified by other or there should be downgrade option. Do you expect people of keep multiple version of the package?
Posted by Dennis Finke She on 6/23/2015 at 7:21 AM
Is there a timescales on delivery ? I don't relish the installation of an older version of visual studio on my pc when the most up to date version should do everything.
Posted by Thomas Bjørndahl on 6/12/2015 at 3:05 AM
I really need a fix for this... now!!
Posted by HollyK on 6/10/2015 at 12:12 PM
Please fix this. We are having to keep multiple versions of Visual Studio up as a workaround.
Posted by RobC21 on 5/20/2015 at 5:59 AM
Does anyone have an update? I only recently found out about this problem after I just created 8 SSIS packages in VS2013 and deployed to SQL Server 2012 ED. I just can't believe that VS2013 is not backward compatible. I need to make a decision today to wait for a fix or re-do all my packages in VS2012.
Posted by Laszlo.T on 5/14/2015 at 1:05 PM
Hi Leo
Could we please have an update on this? We are in the middle of a TFS and SQL server migration. Decisions we make today will be sticking with us for a while. I'm hoping my team can use VS2013 instead of 2012. (VS2015 is just around the corner... don't want to be too many versions behind)
Posted by Mike-EEE on 4/25/2015 at 5:04 AM
Is it fixed yet?
Posted by ChuckAtNDOR on 4/21/2015 at 8:42 AM
I agree with Hikmer, we need an ETA for this "improvement".     Are we going to have the same problem with Visual Studio 2015 support for SSDT-BI?
Posted by Hikmer on 4/21/2015 at 8:11 AM
Really, no ETA for such an obvious pain point for anyone trying to develop SQL SSIS? Do you want us to continue using your product?
Posted by Microsoft on 3/2/2015 at 1:40 AM
Thank you for submitting this feedback. After carefully evaluating the request, we accept the request as a valid issue that we will plan to improve it. We do not have a specific release date at this point but we will release this improvement as soon as we can.

Thanks again for reporting the product issue and continued support in improving our product.

Leo Shum
SSIS team
Posted by zacuke on 1/30/2015 at 2:19 PM
The pain point is that now we have to have both VS 2012 and VS 2013 installed on machines for everyone to be able to open everything in source control. We would expect to migrate everyone at once to VS2013, but because of this we have to keep 2012 around.
Posted by wqwalter on 1/16/2015 at 1:42 PM
The lack of compatibility is a real pain. Especially when the compatibility issues are not clearly explained when the SSDTBI add-ins are released. There is a whole page of people here that have wasted a significant amount of time creating and testing SSIS packages with VS2013 against a SQL 2012 server only to find out that even though it runs fine in the development environment it will fail when deployed. SSISBI knows it is not going to work so why not tell the developer when they add the first connection block that the target server is not supported.

In addition why is SSDTBI ripped out of every initial release of Visual Studio and then very quietly added back in over a year later without adequate warning that 95% of the installed SQL servers are not supported?

Bill Walter
Posted by BFaley on 1/13/2015 at 4:12 PM
This is unbelievably disappointing that these 2 releases (VS 2013 / SQL 2012) are incompatible.
Posted by Chris Rogers on 1/12/2015 at 3:29 PM
Just a side note, I was able get my package to load by editing the file in Notepad++ and changing the <DTS:Property DTS:Name="PackageFormatVersion"> value to 6. I also changed the DTS:VersionGUID to {B2C67EE6-3510-4AD1-B11F-AF84C8DCA75C} and the <Objects Version="sql12"> value to sql11. Not sure if the last two were necessary. So this might be a workaround in some cases.
Posted by O4u InfoSer on 12/17/2014 at 12:07 AM
I am in a similar situation as Christopher06. A major deliverable to a major project was developed with SQLserver 2014 and should be deployed to a SQLserver 2012 environment. As the situation is now ,a downgrade to 2012 from 2014 is not possible for SSIS. I consider this as a major drawback and I advise everybody NOT TO USE SQLSERVER 2014 for the above mentioned reason. I think it is a shame for Micrsosoft to release such a bad product as SQLSERVER 2014.
Posted by Christopher06 on 11/13/2014 at 10:26 AM
I have just run into this issue as well. I am a BI contractor in the Seattle area., and I am about to deliver a solution to a major multi national real estate firm, lets just say this is NOT going to go over well. I have always championed MS products because they simply work together. This defect basically mandates that organization upgrade SQL Server when they upgrade Visual Studio and Team Foundation. When companies see the "all at once" price tag it will cost to upgrade Visual Studio/Team foundation to 2013 because they will be forced to upgrade SQL server as well, they will probably NOT upgrade. I personally will have a very hard time championing upgrades when I can not be certain that the new upgrade are not backwards compatible by even ONE version. This needs to be fixed ASAP. I am very disappointed in MS right now.
Posted by Jim Kay on 10/15/2014 at 7:55 AM
I discovered the lack of compatibility between VS2013 and SSIS 2012 today after spending a couple of hours building and testing an SSIS package using VS2013. It runs just fine from within VS2013, and it even lets me DEPLOY to SQL 2012 without complaint. Once I try to run a SQL Agent job to execute the SSIS package, the job fails with an error related to migrating the package from version 8 to version 6.

Once I realized the limitation of SSDT BI in VS2013 then the question becomes, how do I convert this package down to VS2012? There doesn't seem to be any way to do so. I just have to re-create it from scratch. I can't even copy and paste individual tasks between the versions.

I can understand that not every version of the IDE can work with every version of SQL, but at the least it would be nice if the "Add New Project" wizard in Visual Studio specified these compatibility issues by having the project type be "Integration Services Project for SQL 2014" instead of just "Integration Services Project".
Posted by James Snape (Hitachi Consulting) on 10/7/2014 at 1:58 AM
SSIS2014 and SSIS2012 are supposed to be compatible versions i.e. nothing changed between the two releases. http://msdn.microsoft.com/en-us/library/bb522534.aspx

However, since SSIS 2012 will not execute 2014 packages due to the package version number (which I believe is the only change) we are facing a far more complex upgrade since all developers, deployment scripts and environments need to be synchronized. In all likelihood we will forgo the upgrade to 2014 due to this extra complexity.

Devdiv do a fantastic job ensuring that upgrades can happen on a rolling basis and still be compatible, it would be great if the SQL developer tools would do the same.
Posted by Microsoft on 9/3/2014 at 12:33 AM
Hi dejan1,
Thank you for your feedback. We have investigated this issue. The scope and impact of supporting this does not meet the criteria at this point. But we will consider your feedback in our next major release planning.
Can you share more pain point and user scenario with us?

Sign in to post a workaround.