• Adam Thurgar

Migrating SSIS packages to AWS

We are currently migrating a large amount of SSIS packages (SQL Server 2008R2) to SQL Server 2016 at AWS.

It has been a learning exercise to get these packages running.

What we have learnt (so far) is:

a) that you need to be aware of the solutions deployment target version. By default at AWS it was SQL Server 2017 and this caused some issues with some packages, so we had to save the solution to a target version of SQL Server 2016 and build and deploy on that version. It may be a situation, depending on your packages, that you may need to save to a target version of SQL Server 2014.

b) Be aware of the package protection level and make sure that it aligns with your security requirements, whilst still allowing the package to run.

c) The SQL Server Agent at AWS was running under an NT Service\SQLServerAgent account. To be able to run the SSIS package as a SQL Server Agent job, we needed to create a service account under our own AD and make sure that the account was also part of the local administrators group.

35 views0 comments

Recent Posts

See All

Standardise database sizes and automation

The default setting for the initial sizing of data and log files (and their autogrowth) is not adequate. I like to make sure that we set standard sizes for our data and log files - plus standard sizes

Autoclose and autoshrink - set them to off

By running a simple check of your database settings (use helpdb or query sys.databases) you may find databases that are set to autoclose and/or autoshrink. If so, you should change these settings as p

Report name variable in Sharepoint

Whilst deploying some reports to a new Sharepoint installation I noticed that the global ReportName variable (Globals!ReportName) included the file extension .rdl. This doesn't occur on a native mode