由于Access应用程序往往是以即席(ad hoc)模式创建的，移植难度很大。MySQL用户通常会遇到的两个移植问题是：第一，数据移植问题，由于Access模式设计较差，数据质量很低，往往会造成数据转换过程很复杂;第二，应用程序移植问题，Access应用程序中的窗体和报表常包含了逻辑或设计错误，不可能实现这些文件的自动转换。
成功的移植途径要完成以下三个基本任务：重构模式、清洗数据和重写应用程序。
从Access到MySQL的移植动因
Access数据库由于其操作简单易用，成本较低在中小企业中的市场非常广阔。中等技术程度的部门开发人员都会把Access作为数据库开发的默认选择。大家往往通过将企业数据下载到Excel里，然后将电子表格转换成Access数据库，然后添加即席窗体和报表来构建Access应用程序。由于这些程序由用户组织构建的，所以往往缺乏对数据形式的要求。
在Access应用软件移植上，MySQL用户面临的压力越来越大，包括以下几个方面：
数据质量低下：Access应用程序常常包含了过期的企业数据或来自拙劣定义模式下的损坏数据;
安全性能低下：Access应用程序没有嵌入企业安全组件，不允许进行类似于基于角色的访问控制等的高级安全设置;
可管理性有限：网络技术无法集中管理Access应用程序;
沒有基于网络发布机制：Access应用程序无法通过网络进行访问;
不符合SOX依从性：企业的审核程序往往会把Access应用程序看作是一个重要的风险来源。
数据移植问题
MySQL本身提供了一个数据移植工具—— MySQL Migration Tool。不过这个工具实际上和待转换的数据库的基本模式和数据一样并不好用。而Access的模式和数据质量问题太过深入且普遍存在，所以MySQL用户常常会发现在MySQL从头开始重建数据模式还有来得更容易些。
Access移植过程中最两个常见的与数据质量相关的问题是：
1. Access数据模式不是基于SQL的模式：Access开发人员往往不熟悉SQL模式设计基础。MySQL的数据库管理员会发现，Access模式类似于Excel的电子表格，而和典型的SQL模式相去甚远。例如，这种模式缺乏主键、外键和参照完整性约束。
2. Access数据“不干净”：Access数据库中往往包含很多毁坏的数据，其中部分原因是由于没有对表进行严格定义。有MySQL用户曾经发现在一个Access数据库中，在本来应该是日期字段的区域填入的却是文本字符串。
应用程序移植问题
成功把数据从Access接入到MySQL仅仅解决了一部分问题，还需要处理与Access应用程序相关的窗体和报表问题。此外，你可以把多个Access应用整合成一个web应用;同样的，还可以把多个Access窗体整合成一个网页。虽然可以用ODBC从Access存取MySQL数据，不过大多数MySQL用户还是选择重新编写应用程序。其中的原因包括：
质量问题：鉴于原始的Access应用程序不是由专业的编程人员写的，MySQL用户对其逻辑可行性往往持有怀疑态度。
想要是应用程序适用于网络：大多数MySQL用户都想把Access应用程序转换成动态的网络架构。
出于安全要求：MySQL用户往往希望为程序加入企业级的安全特性，例如Siteminder/LDAP验证和基于角色的访问控制机制等。
虽然有现成的工具可以将Access应用程序自动转换成Java，不过大部分MySQL用户发现自动转换的成功率很低。一条可行的途径是使用类似于PHP的编程语言或ActiveGrid这样的web 2.0 visual builder来接入Access应用程序。
