这些年来，Access数据库一直在PC平台占据主导地位，使用它建立了大量的部门数据库。随着这些数据库的应用，它们中的大多数已经慢慢地具有应急使命，现在需要的是加固成为一个安全的客户端—服务器引擎。
在微软想要统治世界的伟大计划中，更希望这种引擎是SQL Server。随着这种想法，微软针对Access提供了免费的SQL Server移植工具——SSMA。
对于开发者来说，移植工具已有很大的实惠。但期望这种工具能够移植整个应用程序是不现实的，因为Access有一些SQL Server所没有的简单工具（例如窗体和报表性能）。但是我们有理由相信这种工具能做大部分工作，比如建立适当的表，转移数据，把查询转换成视图等。
SSMA的运行需要在.NET Framework2.0版本以上，J#2.0可重组包以及至少1GB RAM。
SSMA具有一个清晰的图形用户界面，分成四个面板。在建立一个新工程之后，首先添加一个或多个Access数据库，然后连接到适当的SQL Server数据库，下一步就是把架构（schema）转换成SQL Server。
注意，这个过程并不是运行依靠SQL Server引擎的架构，而是简单地生成了一个在SSMA中可见的，可用的SQL Server架构，同时生成一个错误、警告和信息标记的集合。
从这点来看，该工具的能力就显而易见。作为一个开始，这些标记指出转换问题，例如：不支持Access的一些函数如DateDiff，所以不能转换（当然这些函数可以被转换，但SSMA不能实现）。
你可以浏览Access架构，观察正在计划的类型映射等等，当然假如你不喜欢这种缺省映射，也完全可以改变它，或者根据特殊的工程甚至特殊的表来做改变。
查询是一个比较特别的情形。它们被转换成SQL Server视图：你可以编辑Access查询然后产生适当的SQL Server代码。这样的编辑是发生在SSMA的架构中，而不是在Access数据库本身完成。
你可以使用SSMA运行依靠数据库的SQL Server架构，它建立了一种结构来保存数据以便你可以移植数据。理论上听起来很好，但是实际上是怎样的呢？虽说尝试从任意一个数据库引擎移植到另一个都是麻烦的，且这个工具可以免费的为你做90%的工作，但它还存在一些缺陷。
例如，虽然不是SQL标准的一部分，Access需要所有日期来包装到hash记号中。不幸的是，SSMA看起来没有考虑到这点，这个疏忽的结果就是所有涉及到日期的查询结果都不能成功转换。下面是一个错误信息的例子：
/* * SSMA error messages: * A2SS0058: Following SQL statement is not supported and cannot be converted: * * SELECT
DISTINCTROW EMPLOYEES.EmployeeNo, EMPLOYEES.FirstName, EMPLOYEES.LastName, EMPLOYEES.DateOfBirth, EMPLOYEES.DateEmployed *
FROM EMPLOYEES * WHERE ((EMPLOYEES.DateOfBirth)>#1/1/1970#); * */
PRINT 'ERROR: SSMA failed to convert the previous statement.'
日期在数据库中是很常见的，所以这个疏忽将会影响大多数数据库转换。但要解决并不困难，如下：
SELECT EmployeeNo, FirstName, LastName, DateOfBirth FROM dbo.EMPLOYEES WHERE (DateOfBirth > CONVERT(DATETIME, '1970-01-01'))
从例子中返回正确的数据集。
（我们可以讨论一下是否是这样，例如：CONVERT(DATETIME, '1970-01-01 00:00:00', 102)可能更恰当，但是不管怎么说，我们可以转换数据处理），假如我们可以手动地做，SSMA就应该可以为我们做这件事。
还有更糟糕的问题：Access默认是在文本周围使用双引号，例如：