Migrating data from Microsoft Access to SQL Server using SQL Server Integration Services (SSIS) involves a few steps. Please note, the following is a generalized explanation and the actual process may vary based on the specificities of your databases.

1. Backup: Begin by backing up your Microsoft Access database to safeguard your data.
2. SQL Server: Ensure that SQL Server is correctly installed and configured.
3. SQL Server Integration Services (SSIS): This is a component of the Microsoft SQL Server, used for a variety of data migration tasks. It is a platform for building enterprise-level data integration and data transformation solutions.
4. Create SSIS Package: Launch SQL Server Data Tools (SSDT) and create a new SSIS package.
5. Configure Connection Managers: Configure two connection managers in the package - one for the Access database and one for the SQL Server database.
6. Data Flow Task: Add a Data Flow Task to the Control Flow. Within the Data Flow Task, add an OLE DB Source (for Access) and an OLE DB Destination (for SQL Server).
7. Configure OLE DB Source and OLE DB Destination: Configure the OLE DB Source to connect to the Access database and select the relevant tables or write a SQL Query to fetch the data. Configure the OLE DB Destination to connect to the SQL Server database and map the columns properly.
8. Execute Package: Run the SSIS package. If everything has been configured correctly, the data will flow from Access to SQL Server.
9. Verify Data: Check the SQL Server database to ensure all data was transferred correctly.

Remember, while SQL Server Integration Services (SSIS) is a viable method for migrating data from Microsoft Access to SQL Server, there are other tools that may simplify the process. One of them is dbForge Studio for SQL Server, a powerful IDE for SQL Server management, administration, development, data reporting, and analysis. This tool offers a user-friendly interface and features to easily migrate data.

A lot of organizations are switching from MS SQL Server to PostgreSQL because the former is a proprietary database from Microsoft, while PostgreSQL is developed and maintained by a global community of open source developers. In terms of cost PostgreSQL definitely offers value.

Having said that, migrating data between heterogeneous database systems (DBMSes) is not easy. There are many factors to consider, such as data type mapping, different syntax, and others. With regards to SQL Server and PostgreSQL, though both databases are ANSI-SQL compliant, there are still differences between their SQL syntax, data types, case sensitivity, and it makes transferring data not so trivial.

The standard approach to migrating between dissimilar databases is to dump the structure and data from the source DB to .sql files. These can then be run on the target database using your favorite command-line or GUI client.

A more robust approach in my opinion is to use a specialized tool like Navicat Premium. It’s especially well suited for migration tasks because it can connect to multiple databases simultaneously as well as migrate data between them in a seamless and consistent way. It can also migrate other database objects besides tables, including Stored Procedures, Events, Triggers, Functions, and Views.

There’s a Data Transfer wizard that lets you select the Connection and Database of the data source and target DB. You can migrate Tables, Views, Procedures, Functions, and Events:

On the Advanced tab, there are many additional options that pertain to the target database type selected, for example, Lock source tables, Lock target tables, Use extended insert statements, Use delayed insert statements, Run multiple insert statements, and Create target database/schema.

Progress will be relayed on the Message Log tab.

You can save all of your import settings as a profile using the Save button. All you need to do is supply a profile name.

You can then refer to the saved migration script from an Automated Job. That’s a scheduled batch job that runs daily tasks. You can receive notification e-mails upon tasks completion.

That’s what I would recommend based on my own experience.

It’s fairly easy to use so you really can’t go wrong. It’s not a free product but there is a 14 day trial, so you can try it out and see if it works for you.

Best of luck!

Adam

As much as humanly possible, you use tools to do the work. However, the tools can’t automatically generate scripts in all situations. Sometimes, you’ll need to write some scripts yourself. So, the key here is to create your automation processes such that you can take into account these manual scripts when they come up.

When we start talking about automating change scripts for databases, there are two basic approaches. The first, the one used by SSDT, is called State. It compares two states and arrives at a difference script. The states can be databases (prod vs. dev), backups (dev vs. qa) or source control (source control vs. whatever). You compare the two and arrive at a difference script. However, depending on the changes entailed, most engines can cause data loss with the automatic generation.

The second approach is called Migrations (has a bunch of different names, this is the one I’ve stuck with and promote). Basically you build a manifest of scripts that have to be run in a particular order. There are tools that support this method. Here, you can easily insert your manual script in the appropriate spot and be done.

Migrations really is the easiest to set up and maintain, but it has a few issues. What we really need is a fully hybrid approach that lets us use Migrations from State. I don’t know of any tool that does this well, yet.

You can also add steps to your flow control software (Jenkins, Octopus, Azure DevOps, GitLab, whatever) to allow for pre/post-scripts to run to deal with some of these issues.

I have not listed particular tools in this because I work for a vendor (Redgate Software) that makes software specifically for this. I’d rather you got the information than a sales pitch. If you want to follow up in the comments, I can suggest tools to help out.

Asked to answer.

Several tools are available for migrating data from SQL Server to Microsoft Azure, each with its own features and advantages. Here are some popular options:

1. Azure Database Migration Service: This fully managed service simplifies the migration process. It supports online migrations, minimizing downtime, and supports various source databases, including SQL Server. It provides a guided experience with minimal manual intervention.

2. SysTools SQL to Azure Migration Tool: This is so far the most reliable utility that users can trust as no other use is capable of the same. Moreover, this is also the best one in terms of features & budget among all other solutions.

3. SQL Server Management Studio (SSMS): If you're comfortable with SSMS, it includes a database migration wizard that can assist with migrating on-premises SQL Server databases to Azure SQL Database or Azure SQL Managed Instance. However, it’s not the ideal one due to many limitations.

4. Azure Database for MySQL, PostgreSQL, etc: If you're migrating to other database platforms like Azure Database for MySQL or Azure Database for PostgreSQL, tools specific to those platforms might also be helpful.

There are several essential data migration tools that you can consider depending on your specific needs and requirements.

1. **AWS Data Migration Service (DMS)**: A fully managed service for migrating data to and from various AWS data stores.

2. **Microsoft Data Migration Assistant**: Helps you assess and perform database migrations to Azure SQL Database.

3. **Google Cloud Database Migration Service**: Facilitates migrating databases to Google Cloud.

4. **Talend**: An open-source data integration tool that supports data migration.

5. **Apache Nifi**: An open-source data integration tool that can be used for data migration and ETL (Extract, Transform, Load) tasks.

6. **Liquibase**: An open-source database migration tool that helps manage and version your database schema.

7. **Apache Sqoop**: Useful for bulk data transfer between Hadoop and relational databases.

8. **Trifacta**: Offers data wrangling and transformation capabilities that can be useful in migration projects.

9. **Attunity Replicate (now part of Qlik)**: Provides real-time data integration and migration solutions.

10. **RoboCopy**: A command-line tool for Windows that's useful for copying large volumes of data.

11. **Rsync**: A popular tool for efficiently transferring and synchronizing data between systems.

12. **Carbonite Migrate**: Designed for server migrations, especially in virtualized environments.

13. **Code-based migration tools**: Depending on your use case, you might also write custom scripts or use programming languages like Python or Java to perform data migration.

Remember that the choice of tool should align with your specific migration requirements, such as source and target systems, data volume, data complexity, and whether you need real-time or batch migration.

Data migration is a critical process when you need to transfer data from one system to another, such as upgrading databases, moving to the cloud, or consolidating systems. Several essential data migration tools and platforms can help streamline and ensure the success of your data migration projects.

Below are some of them:

• AWS Database Migration Service (DMS): This service by Amazon Web Services is designed to migrate databases to and from the AWS cloud. It supports a wide range of database platforms.
• Microsoft Data Migration Assistant: This tool helps you assess your databases for migration to Azure, and it provides a step-by-step guide for the actual migration process.
• Google Cloud Data Transfer Service: Google Cloud offers several data transfer and migration tools, including the Data Transfer Service, which simplifies the migration of data to Google Cloud Storage.
• Talend: Talend provides a comprehensive suite of data integration and transformation tools, including those for data migration, data quality, and ETL (Extract, Transform, Load) processes.
• Informatica PowerCenter: Informatica offers a powerful data integration platform that includes tools for data migration, data synchronization, and data quality.
• SnapLogic: SnapLogic is a cloud-based integration platform that offers a visual interface for designing data integration and migration workflows.
• Attunity (now part of Qlik): Attunity provides solutions for data replication, ingestion, and migration, especially useful for big data and cloud environments.
• IBM InfoSphere DataStage: IBM's ETL tool, DataStage, is well-suited for data migration tasks, especially within complex enterprise environments.
• Oracle Data Integrator (ODI): Oracle's ODI is an ETL and data integration tool that can be used for data migration and transformation tasks, particularly within Oracle environments.
• Apache Nifi: An open-source data integration tool, Nifi is often used for ingesting, transforming, and moving data between systems. It's versatile and can be used for data migration.
• Syncsort: Syncsort offers data integration and data migration solutions, particularly for mainframe data migration.
• Flyway: If you need a tool for database schema migrations, Flyway is an open-source tool that helps manage and version control your database schema changes.
• Liquibase: Similar to Flyway, Liquibase is an open-source tool for database schema versioning and management.
• CloverDX: CloverDX is an enterprise data integration platform that can be used for data migration and ETL processes.
• Open Source ETL Tools (e.g., Apache NiFi, Apache Camel, Talend Open Studio): Depending on your requirements and budget, open-source ETL tools can be powerful for data migration, particularly in non-enterprise environments.

Importing data from a MySQL table into SQL Server is possible with the help of the ODBC driver for MySQL and Data Pump for SQL Server. Problems with compatibility, data integrity, and performance are just a few of the numerous potential roadblocks that may arise throughout the extremely complicated process of migrating data from MySQL to SQL Server.

Remember that SQL Server and MySQL differ in supported capabilities, data types, and syntax when attempting to ascertain compatibility.

Verify and adjust the data types, migration order, and foreign key limits to guarantee the data remains intact. Maintaining up-to-date dependencies is essential.

Make any required adjustments to the target database's queries and indexes. Determine where the MySQL database is vulnerable and then strengthen it using SQL Server.

This post will teach you all you need to know about MySQL and SQL Server so you can easily transition between them. This article shows you how to import data from a MySQL table into SQL Server using the ODBC driver for MySQL and Data Pump for SQL Server.

1. Apache NiFi
   Why: NiFi offers a user-friendly interface for designing data flows and supports real-time data migration with scalability. Its ability to handle data transformations and routing makes it ideal for complex migrations.
2. AWS Data Migration Service (DMS)
   Why: DMS simplifies cloud migrations, especially to AWS. It supports continuous data replication with minimal downtime, making it suitable for migrating large databases to the cloud.
3. Microsoft Azure Data Factory
   Why: Azure Data Factory integrates seamlessly with Azure services and enables batch and real-time data migrations. Its visual interface allows easy creation of data pipelines.
4. Talend Data Integration
   Why: Talend provides robust ETL capabilities and supports data quality checks during migration. Its open-source version and enterprise tools make it versatile for various data environments.
5. IBM InfoSphere
   Why: This tool offers advanced features for large-scale enterprise data migration, including data governance, cleansing, and security.
6. Google Cloud Dataflow
   Why: Ideal for real-time data streaming and migration on Google Cloud, Dataflow supports dynamic scaling and simplifies data transformations.

For professional data migration services, Ksolves offers expertise in integrating these tools to ensure seamless, efficient migrations tailored to your needs.

Our group has a project where we are doing the opposite—moving an application from Oracle to SQL server. In our case, the application needs to function the same way as before, but only change the database. The application had to change so that any functions or packages in Oracle could be emulated in SQL Server. You will need to do the reverse.

You could use the SQL Server Import and Export Wizard if you have a relatively small database. I keep track with spreadsheets to make sure each converted object has been converted and tested—or accounted for if it will be dropped during the conversion.

The first thing to migrate are tables. You can dump out data from both and compare if all the data migrated properly. If you have data more than 1 million rows, you will need to compare those tables across database links instead of in Excel spreadsheets. Another approach is to migrate data to your target database and back to see if you’ve lost anything in the migration. SELECT with MINUS is slow but reliable.

You will need to understand your constraints. Applying primary keys and foreign keys will be an eye-opening experience.

Identity columns are handled differently in the two systems. Oracle creates a system sequence and a trigger to get the same effect. Truncating a table doesn’t reset the sequence to 1. Your application will have to account for that subtlety.

The most fun you will have will be with stored procedures and triggers. Going from T-SQL to PL/SQL will drive you nuts. They are two different worlds of syntax.

Oracle does have PDBs, but I don’t recommend using links across them. Use different schemas within the same database instead. Oracle doesn’t have a “dbo” schema.

Views aren’t so bad. Joins have similar syntax. If you have joins across databases, you might want to consider using schemas instead. That may require some other redesign.

Have a plan (yes, Dorothy, this means documentation). Make a list of all your objects in a spreadsheet. Have a pass/fail criterion for each one. Give yourself plenty of time. Ultimately it will be your application that will tell you if you’ve done a good job. That will be part of your user acceptance testing to make sure all the bells and whistles ring and toot the same way as before.

Good luck!

SQL Server Compact & SQLite Toolbox 4.4 & 4.5 – Visual Guide of new features

This person going by ErikEJ has done a remarkable job with his freely available tools that allow for every permutation of what is possible between SQL Server (all versions), SQL Compact Edition (3.5 and 4.0), and SQLite. To address the specific question - migrating from SQL Server to SQLite - he has provided several ways to do this. His documentation is superb so I will bother restating things found there (above link). But I will say that there are ways to do this with his tools from SSMS, Visual Studio, and even the command line to ultimately automate the process. What also is great is that migrating databases is not some hidden esoteric functionality that is possible but really hacked up ; rather Erik has thought very deliberately about migration and has explicitly provided all the combinations one could need right from the context menu. You can Script :

-Schema only

-Data only

-Schema and data

And all of these can be done for:

SQL Server -> SQLite

SQLite -> SQL Server

SQL Server -> SQL CE

SQL CE -> SQL Server

SQL CE -> SQLite

SQLite -> SQL CE

This question is written in detail on Wikipedia. In short, SQL developer tools are, quite obviously, designed to make SQL coding fast and easy. Take dbForge SQL Tools for example. It's a collection of apps and add-ins for SQL Server Management Studio that serve a variety of purposes.

• SQL Complete helps you code faster with code completion and refactoring. It also helps beautify your code and make it easily readable with formatting.

• Query Builder helps you construct queries on diagrams. It's convenient and doesn't require coding, so some of you might want it at hand.

• Data Compare finds differences in your table data and syncs these differences the way you need. Schema Compare is a similar tool that works with database schemas.

• Data Pump deals with data import and export and has more than a dozen supported data formats.

• Data Generator helps you get valid dummy data for testing. Speaking about testing, Unit Test does what its name says and is a great helper.

• Source Control works with Git, Mercurial, Azure DevOps, SVN, and a couple other version control systems.

• There are a few other handy add-ins for DBAs.

One of the main strengths of this toolset is that it works with the command-line interface, and most of the tasks you have can be easily automated.

Or, if you want to have it all in a single app outside of SSMS, take their IDE dbForge Studio and give it a shot. It has all of the features I've mentioned.

“How do you migrate an SQL server database to PostgreSQL?”

Carefully.

The issue is that not all data types map simply. Not all code will migrate cleanly. Not all functionality exists on both sides, and certainly not in the same form. I’ve been working on a little project on the side to do just that, migrate some SQL Server databases to PostgreSQL for testing, development and training (mine as well as others). It’s a tedious process that I haven’t found a good automation mechanism for just yet.

The biggest key is going to be to focus not on the simple stuff, NULL is the same in both, VARCHAR is the same in both (mostly), etc.. No, you have to focus on the things that exist in one, but not the other. For example, spatial data in SQL Server is pretty straight forward. Spatial data in PostgreSQL is either more than a little mucky if you’re using strictly the internal geometry data types (which don’t really support spatial as such), or you have to install PostGIS to get the full functionality. This simple example is not a showstopper and I’m not offering criticism of PostgreSQL. It’s just one tiny example of where you may find a straight mapping of functionality hard. There are going to a lot of this type of example.

None of this should prevent you from making the transition if, after evaluation and testing, you decide that PostgreSQL is a better solution for your environment. It’s just all things you should take into account when you start planning the project and the very necessary testing at the end of it.

Asked to answer.

I can not look in your pocket of course, yet you might want to look at upgrades. Many previous enterprise versions features are now in server. As you know all SQL version(express, server and enterprise) have the same code base. The version difference causes certain optimizations to be switched on/off. So you might want to look at 2019 version. It is substantial faster. The same is true for hardware. Very likely older version also means older hardware. I recently installed a handful of Intel NUCs as replacement for a VMware solution. Just by reducing licenses alone I can buy a NUC monthly. And with it come thundering performance. Some queries run over 50x faster. It changed my mind. Maybe we have reached the point where simplicity of components and stability of current OS and hardware makes it worthwhile to treat services as dedicated components.

When it comes to efficient data analysis beyond Python and SQL, esProc SPL may be a suitable but often overlooked option. SPL is designed for handling complex data processing tasks with streamlined, readable code. It solves data tasks with much simpler syntax than SQL or Python, achieving the same results in fewer lines and making it easier to troubleshoot or optimize.

Talk is cheap. Let’s show the code directly.

For example, a task to count user sessions (A session is considered over if a user does not take any action within 10 minutes, or if they do not log in within 5 minutes after logging out.), and we want to calculate the number of sessions for each user.

Here’s the source data table:

userid	action_type	action_time 
U1059	login	2023-12-01 18:00:10 
U1092	login	2023-12-01 18:00:17 
U1069	login	2023-12-01 18:00:22 
…	…	… 

The SPL code for this task:

	A 
=file(“session_data.csv”).import@tc() 
=A1.group(userid;~.group@i((action_type[-1]==“exit”&&interval@s(action_time[-1],action_time)>300)||(interval@s(action_time[-1],action_time)>600)).len():session_num) 

SQL

WITH login_data AS ( 
    SELECT userid, action_type, action_time, 
        LAG(action_time) OVER (PARTITION BY userid ORDER BY action_time) AS prev_time, 
        LAG(action_type) OVER (PARTITION BY userid ORDER BY action_time) AS prev_action 
    FROM session_data) 
SELECT userid, COUNT(*) AS session_count 
FROM ( 
    SELECT userid, action_type, action_time, prev_time, prev_action, 
        CASE 
            WHEN prev_time IS NULL OR (action_time - prev_time) > 60  
                OR (prev_action = 'exit' AND (action_time - prev_time) > 300 ) 
            THEN 1 
            ELSE 0 
        END AS is_new_session 
    FROM login_data) 
WHERE is_new_session = 1 
GROUP BY userid; 

Python

login_data = pd.read_csv("session_data.csv") 
login_data['action_time'] = pd.to_datetime(login_data['action_time']) 
grouped = login_data.groupby("userid") 
session_count = {} 
for uid, sub_df in grouped: 
    session_count[uid] = 0 
    start_index = 0 
    for i in range(1, len(sub_df)): 
        current = sub_df.iloc[i] 
        last = sub_df.iloc[start_index] 
        last_action = last['action_type'] 
        if (current["action_time"] - last["action_time"]).seconds > 600 or \ 
            (last_action=="exit" and (current["action_time"] - last["action_time"]).seconds > 300): 
            session_count[uid] += 1 
        start_index = i 
    session_count[uid] += 1 
session_cnt = pd.DataFrame(list(session_count.items()), columns=['UID', 'session_count']) 

ERwin has long been a heavyweight in the space. Have not used it in a few years, but previously thought it was a powerful tool with just an OK interface. You can download the community edition here for a look-see:

Free data modeling tool - CA ERwin

SQL Server's built in modeling tools have really improved over the years and are worth a look too. For simple projects (in the dozens of tables or hundreds of columns) SQL Server Management Studio isn't a bad place to start.

The important thing to realize is that none of these tools will hold your hand and architect the "right" database for you. They all require you to have some concept of relational database theory and constraints, ie primary and foreign keys, unique constraints, etc. But it's very nice to go from visual model to database creation, and to update the model first when adding columns, keys, etc.

In particular I have become a fan of using the comment feature of SSMS to document the database as I go. There is a lot of important metadata about various tables and columns that traditional modeling tools don't capture (business rules associated with a table or column, expected range of values, what it "means" when a foreign key to another table does or doesn't exist, etc). Example: a column called "book_id" might have a comment that says "ISBN number of book, if exists; if NULL then PDF or unpublished draft" or some such thing. Like all documentation, it helps both fellow team members and future ones (eg the poor bastards who will inherit your work someday and have to decipher it).

SSIS packages are an object heirarchy, and the PackagePath is the path to the property being configured.

Connection managers are in the Connections collection, so a connection manager property would be similar to “\Package.Connections[<connection name>].Properties[<property name>]”, where common property names are ServerName, InitialCatalog, UserName, and Password.

A Task property would be “\Package\<task name>.Properties[<property name>]”.

Variables are in the Variables collection, so their path might be “\Package.Variables[User::<variable name>].Properties[Value]”. (User is the default namespace for variables, it may be different.)

Tasks and variables may be nested inside other containers, which will add more levels to the path.

This task is not at all difficult until users are well aware of the right solution. There is no direct solution available to execute this task manually. For the manual method, users have to use a three-phase technique to migrate a SQL server 2008 R2 database to SQL server 2019 version. Now as we are focusing on the major migration task, the difference between both server versions is quite big.

Hence, we’re going to choose the automated solution. Here, users need to focus on using the automated SQL Server Migration Tool. this solution is expert recommended & can easily provide the desired results in just four simple steps.

Step-1. Launch this Tool & Go to the Open button to proceed further.
Step-2. Select the Online or Offline Mode as per your requirements.
Step-3. Adjust Export Settings & Mention the Destination server.
Step-4. Finally, Hit the Export button to finish the task with accuracy.

If you interested in executing the migration from SQL server, the task is quite easy if you are aware of the right tool & technique. Migrating an SQL server database from a lower version to a higher one is quite easy. Simply Download the automated tool from Emaildoctor & then follow the five steps mentioned below:

Step-1. Launch Tool in your system & Click the Open button.
Step-2. Select the Online or Offline Mode for migration here.
Step-3. Preview Database Objects & then Go to Export options.
Step-4. Now, Adjust the Export options as per your requirements.
Step-5. Finally, Click on the Export button to finish the task.

I’d advise you go low-code if you’re thinking about “fastest”. Now if you were asking about the fastest for a complex web application, you’d want an application with a comprehensive component set so you don’t have to code from scratch.

But before you select any platform at all, note down the features you need in the application, the personas of users that’ll be using the platform (devs, non-devs, designers, etc), hosting options, and development budget.

You can check out Reify low code. It’s built specifically for large enterprises in several top industries including financial analysis, medical research and insurance, and more. Plus you could even get started and set all these up as a non-developer. There are others like Outsystems with equally good features but made specifically for developers, or PowerApps that’s made for non-devs but developers may find it very limiting.

The “best” tool just depends on what you’re looking for.

Disclaimer: I work with Isomorphic Software – the company behind the Reify low code platform.

You can use bipp Analytics BI platfrom and bippLang data modeling language that streamlines SQL (while working with different SQL dialects including MS SQL) and helps you create reusable complex data models with custom columns and dynamic sub-querying: bippLang Data Modeling Language
The platform connects to all major databases and supports the associated SQL syntax, making the bippLang dataset an abstraction layer above SQL.

This way, data modeling bridges the technical and business worlds. A data model must both support and enable business processes and decisions. And building a data model requires both technical skills and an understanding of how your broader business functions: The Art and Science of Data Modeling

SQL developer are folks who write SQL scripts that insert, delete and update data in a database. This field is fairly complex. Involves, writing stored procedures, function et al. In current context, the database refers to Microsoft SQL Server.

There is no such thing as ‘SQL Server developer’. May be they wanted to distinguish from Oracle PS/SQL, MySQL or NoSQL databases.

SSIS and SSRS are very different products in Microsoft Database ecosystem, and are closely integrated with SQL server. SSIS is an Integration Server which integrates various databases running on different servers such as Oracle, MySQL among others. SSRS is a reporting server which is an important part of any business. You can author and run reports with it.

The skills / certifications required for each are very different from one another but with fair overlapping.

Yes. I am not at all certain it would be easy, but according to the documentation, it can be done.

That said, I think you would be FAR better off generating a script to create the tables and indexes, and reviewing them to make sure they are correct for an SQL Server instance. Once that is done, create a link to the Oracle database (this can be done in SQL Server Studio) and then execute a query for each table to move the data.

Of course, there can be LOTS of other things in an Oracle database than just tables and indexes. Any procedures, functions or packages would have to be translated to T-SQL. I am not so certain about triggers, libraries, views (materialized. mostly), sequences, data types and of course, users and roles. So they should be approached with caution and care.

I do know with certainty that way back when, the application I have worked on for the past 19 years (installation, configuration and data migration) had a version that used an SQL Server database back in the early 2000s. When the application was re-written in Java (~2004–2005), they abandoned SQL Server because they moved a lot of stuff into procedures, and could not get the PL/SQL packages to work in SQL server, as T-SQL was just not advanced enough (at the time).

As Mark Twaine alluded to, you may have a LOT of testing ahead of you to make sure everything is working correctly. I have never used SSMA and so cannot give it any rating.