Migrating from iBATIS to MyBatis

A Mechanical, Well-Trodden Path

Migrating iBATIS 2.x to MyBatis 3 changes packages, a few statement tags and the client API. The SQL itself mostly survives untouched.

Step-by-Step

1. Swap dependencies: remove iBATIS jars, add mybatis (and the Spring starter when you use Spring).
2. Rename configuration: SqlMapConfig.xml becomes mybatis-config.xml with the same data source sections.
3. Update DOCTYPEs: map files declare the mybatis-3 DTD and the mappers config references them.
4. Change the client: new SqlSessionFactory replaces SqlMapClientBuilder (they map feature-for-feature).
5. Introduce mapper interfaces: replace statement-string calls with interface methods, or keep statement ids for a smooth path.
6. Retag dynamic SQL: #x# becomes #{x}; <isNotEmpty> becomes <if>; <dynamic> becomes <where>/<trim>.

Statement Call Before and After

// iBATIS 2
Customer c = (Customer) sqlMap.queryForObject("Customer.getCustomer", id);

// MyBatis 3
Customer c = session.getMapper(CustomerMapper.class).findById(id);

Key Points

• Configuration and mapping concepts translate directly.
• Retag dynamic SQL and change #x# to #{x}.
• Replacing string keys with mapper interfaces is optional and gradual.
• Most migration effort is mechanical; SQL rarely changes.