When running the migration tool shipped by BPMS 6.1 against repository generated by BRMS 5.2, a couple of issues occur:

1) SimpleDate format issue:
In 5.2, any rule that uses a java.util.Date produces the following line in the .rdrl file:
java.text.SimpleDateFormat sdf = new java.text.SimpleDateFormat("dd-MMM-yyyy");

During migration, however, the line is transformed to an invalid form that will throw exceptions at runtime:
java.text.SimpleDateFormat sdf = new java.text.SimpleDateFormat("null");

If I save the file via the 6.1 UI, the SimpleDateFormat line no longer exists in the rule. Since we have over a hundred projects, that is not necessarily a valid option.

2) Disabled rules in 5.2 are included in compilation in 6.1 - Example:
gov.hhs.cms.ffe.rules.ee.eligibilitydetermination.aptceligibility - BTW100And400FPL_ESCOrNonESI

This rule was disabled in 5.2(see attached screenshot) but again is available after running the migration tool.

3) Several migrated rule packages are empty:
gov.hhs.cms.ffe.rules.ee.eligibilitydetermination.medicaidchipmagieligibility.titleiiworkquartersapplicantspouseparents
gov.hhs.cms.ffe.rules.ee.eligibilitydetermination.medicaidchipmagieligibility.setparentorcaretakercategory
gov.hhs.cms.ffe.rules.ee.processescmecverification.evaluateattesteddata.esccompatibilitycheck
gov.hhs.cms.ffe.rules.ee.eligibilitydetermination.medicaidchipmagieligibility.unbornchildcategory
gov.hhs.cms.ffe.rules.ee.householdincome.verifyannualincomeforaptc
gov.hhs.cms.ffe.rules.ee.householdincome.verifyincomeformedicaid
gov.hhs.cms.ffe.rules.ee.householdincome.determineexitexpeditedincomequalifier.verifytaxandmedicaidhouseholdsize

I can see some errors related to parsing this package:

[Fatal Error] 8eebc1f1-36f9-44eb-9fee-b2cd3b6a18c5.xml:575:104: The value of attribute "name" associated with an element type "null" must not contain the '<' character.
org.xml.sax.SAXParseException; systemId: file:/home/ghu/java/jboss/bpms/6.1.0.GA/jboss-brms-bpmsuite-6.1.0.GA-redhat-2-migration-tool/bin/tmp-jcr2vfs/8eebc1f1-36f9-44eb-9fee-b2cd3b6a18c5.xml; lineNumber: 575; columnNumber: 104; The value of attribute "name" associated with an element type "null" must not contain the '<' character.
at com.sun.org.apache.xerces.internal.parsers.DOMParser.parse(DOMParser.java:257)

8eebc1f1-36f9-44eb-9fee-b2cd3b6a18c5.xml:
Here is the line 575:
***************************************************************************************
]]></textContent><history><assets></assets></history></asset><asset name="datePersonCouldStartCoverage <= proposedOEPCoverageEffectiveDate when F or G" type="brl" lastContrib="admin" lastModif="1411398799952"><comment><![CDATA[unarchived]]></comment><content><![CDATA[rule "datePersonCouldStartCoverage <= proposedOEPCoverageEffectiveDate when F or G"
***************************************************************************************
dialect "mvel"
when
applicant : ApplicantEscMecVerificationVO( memberId != null , offerings : currentOfferings != null , coverageStartDate != null )
forall(AttestedOfferingBenefitDataVO(isEnrolled != "Y") from offerings)
applicantResponse : ApplicantEscMecVerificationResponseVO( memberId == applicant.memberId , edsEscStatusIndicator == "F" || == "G" , attestedOfferedCoverage == "Y" , offeringsResponse : attestedOfferingBenefitDataResponse != null , proposedOEPCoverageEffectiveDate != null && >= applicant.coverageStartDate )
offeringResponse : AttestedOfferingBenefitDataResponseVO( escMECIndicator != "N" , currentQualifyingCoverageVerification != null , currentQualifyingCoverageVerification.hasAffordableMVESCIndicator == "Y") from offeringsResponse
then
java.text.SimpleDateFormat sdf = new java.text.SimpleDateFormat("null");
applicantResponse.setApplicantESCStatusIndicator( "Y" );
applicantResponse.setApplicantESCStatusDeterminationDate( new Date() );
applicantResponse.setApplicantESCStatusInconsistencyReason( "999" );
applicantResponse.setApplicantESCSamplingApplies( "Y" );
end

The parsing errors start throwing when the rule contains:
java.text.SimpleDateFormat sdf = new java.text.SimpleDateFormat("null");
Therefore, I think this might be related to the issue #1.