Is it possible to use SSIS 2014 on SQL2008R2 ? By installing any of SSIS2014 redistribution components on SQL2008R2

As far as I know, you are out of luck & will have to develop the packages again in the old format.
SSDT 2015 allows the targeting of all versions back to 2012, but that's as far back as it goes.

It is not possible to install only SSIS 2014, though it is perfectly feasible for you to install an instance of 2014 which is dedicated to SSIS and use that.

Hi All, 

Thanks to every one for your valuable inputs .

Scenario: We have developed SSIS packages in SQL Server 2014 version and all the packages are running successfully. Now we have a challenge that our old clients also want to deploy these SSIS packages in their machines, but they are still running with SQL Server 2008 R2. And they don’t want to migrate to 2014. Now here the main question for our tech team is
How to execute SSIS 2014 packages from the SQL Server 2008 R2 ?
As we did some R & D on this here we have few points which will help to us
1.       There is no backward compatibility for 2008 R2 from any upper edition
2.       There is backward compatibility in SQL Server 2015 to 2016/2014/2012 as target version
3.       Changing version numbers alone in the SSIS packages will not work, as we need to also change the code and there is no 100% accuracy
4.       Or we have to develop all the packages in 2008 – it’s tuff, duplication of work and time wasting process (from the Management & Developer point of view)
So, after long discussions between us & we come to know that, we can do this by installing only SSIS 2014 (as shown in below image - SQL Server 2014 Developer Edition) on the same machine where SQL Server 2008 R2 is installed.
 
After installing this we tried to execute the SSIS 2014 version package from command prompt as shown below. But still we are getting incompatibility errors. (here SSIS packages is developed in SQL SERVER 2014 version and the Data is pointed to the SQL Server 2008 R2 version )
DTEXEC /FILE "E:\TVN\PRISMA ETL 2014\TempDate_Load.dtsx"
But If I run the same package from the visual studio it’s running and I can see the updates on respective data base.
We got to know that by default DTEXEC is trigging from the 2008 as system taking it as default.
Now we executed the same package from SQL Server 2014 installed path (as shown below ) and completed successfully
C:\Program Files (x86)\Microsoft SQL Server\120\DTS\Binn\DTEXEC /FILE "E:\TVN\PRISMA ETL 2014\Main Package.dtsx"
Now we have to configure this in Jobs at SQl Server 2008 R2, did this as shown below and working fine.
It will run only from Type as “Operating System” option

Thanks,
Venkat

Well done on working things out, but I do have a couple of comments:

• You did not just install SSIS 2014, you installed SQL Server 2014 with SSIS 2014. SSIS cannot be installed on its own.
• SQL Server Development Edition should be used only for, err, development. Anything else and you are violating the terms of the licence and are opening your client to the possibility of a large fine, in the event that they are audited by MS.

Another workaround which avoids the use of developer edition and the licencing issues around that is as follows:

1. Install SQL Server 2014 Express edition on the host, this will place the binaries required to run dtexec, you can disable all the services.
2. Place your ssis packages in a suitable location i.e. D:\SSDT\Packages
3. Create a batch file to run your package, for example:

"C:\Program Files\Microsoft SQL Server\110\Tools\Binn\dtexec.exe" /f "D:\SSDT\Packages\MyPackage.dtsx" > D:\SSDT\Logs\MyPackage_Example_Process_log.txt

4. Setup a SQL Agent job to call the batch file as an operating system task.

We have something similar setup to allow the execution of packages on a EC2 instance hosted in AWS where we have no need for a full SQL server (we use task scheduler for automation).  There are some limitations as to what tasks work but for our needs it works well.

Sorry yes, this particular example is for SQL 2012, but the same works for SQL 2014.  We have been running this very setup for almost 2 years.  As I say it has its limitations in what tasks will work within a package, but the most common execute SQL \ DFlow tasks work.