The following is taken verbatim from Perkins, David, and McGinnis,Evan, Understanding SNMP MIBs,
Prentice Hall PTR, 1997, pages 212-214.  Their contribution is gratefully acknowledged.

Converting an SNMPv2 MIB to SNMPvl
  Even though there are a number of excellent tools for converting a module written in SMIv2 
syntax into the SMIvl syntax, we need to examine exactly what is involved in this process.
	1. Translate the IMPORT statements to refer to the appropriate SMIvl types and 
	modules. Typically, this will be RFC1155-SMI and RFC-1212.
	2. Translate the OBJECT-TYPE statements to the SMIvl format using these rules:
		* Replace AUGMENTS with INDEX.
		* Comment out any UNITS clauses.
		* Replace the ACCESS value read-create with read-write.
		* Replace the STATUS value current with mandatory.
		* Replace every SYNTAX value of Counter32 with Counter, Gauge32 with Gauge, 
	and Unsigned32 with Gauge.
	3. Comment out any OBJECT-TYPE whose SYNTAX value is Counter64. As this type has no 
	equivalent in SNMPvl, objects of this type can't be properly translated. It would be
	 nice if there were an alternative, but there is no agreed upon way to get around
	 this restriction.
	4. Translate the definitions that follow into simple OID assignments, and comment 
	out all other clauses: MODULE-IDENTITY, OBJECT-IDENTITY, OBJECT-GROUP, 
	NOTIFICATION-GROUP, MODULE-COMPLIANCE, and AGENT-CAPABILITIES. Here's what we mean 
	by this:
  
  mdmMIB MODULE-IDENTITY
    LAST-UPDATED "9406120000Z"
    ORGANIZATION "IETF Modem Management Working Group"
    CONTACT-INFO
          " Steven Waldbusser
          Postal: Carnegie Mellon University
          5000 Forbes Ave
          Pittsburgh, PA, 15213
          US
          Tel:+l 412 268 6628
          Fax:+l 412 268 4987
          email: waldbus.ser AT cmu DOT edu"
  DESCRIPTION
          "The MIB module for management of dial-up modems."
  ::= { mdmMib 1 )

Converting this into a simple assignment and the fields commented out:
  mdmMIB OBJECT IDENTIFIER ::= { mdmMib I }
  -- MODULE-IDENTITY 
  -- LastUpdated
  -- 9406120000Z
  -- OrgName
  --   IETF Modem Management Working Group 
  -- Contactlnfo
  --	          Steven Waldbusser 
  --  Postal: Carnegie Mellon University 
  --          5000 Forbes Ave 
  --         Pittsburgh, PA, 15213 
  --         US
  --
  --     Tel: +1 412 268 6628 
  --     Fax: +1 412 268 4987 
  --    email: waldbusser AT cmu DOT edu
  -- Descr
  --   The MIB module for management of dial-up modems.

	5. Translate NOTIFICATION-TYPE to a TRAP-TYPE using these rules:
  		* Change the OBJECTS clause to VARIABLES
  		* Comment out the STATUS clause
  		* SNMPv2 notifications are designed with SNMPv1 Proxy compatibility in mind by requiring 
    		that they are registered as oidVal.O.id. Some older notification specifications use a 
    		form which omits the 0 sub-identifier: oidVal.id. If the notification being translated 
    		is in this format, then the ENTERPRISE clause of the new TRAP-TYPE is oidval, and the 
    		value of the trap is id. For notifications registered as oidval.id, the ENTERPRISE 
    		clause is oidval.
For example:
    upsTrapOnBattery NOTIFICATION-TYPE
          OBJECTS {
                 upsEstimatedMinutesRemaining, upsSecondsOnBattery, 
                 upsConfigLowBattTime }
          STATUS current
          DESCRIPTION
                  "The UPS is operating on battery power. This trap is 
                  persistent and is re-sent at one minute intervals until
                  the UPS either turns off or is no longer running on 
                  battery."
         ::= { upsTraps 1 }

Changes to:
    upsTrapOnBattery TRAP-TYPE
          ENTERPRISE upsTraps
          VARIABLES {
                  upsEstimatedMinutesRemaining, upsSecondsOnBattery, 
                  upsConfigLowBattTime }
          STATUS current
          DESCRIPTION
                  "The UPS is operating on battery power. This trap is 
                  persistent and is re-sent at one minute intervals until
                  the UPS either turns off or is no longer running on 
                  battery."
         ::= 1


	6. Translate TEXTUAL-CONVENTION to a simple type assignment, and comment out the fields.
For example:
     PhysAddress ::= TEXTUAL-CONVENTION 
           DISPLAY-HINT 	 "lx:" 
           STATUS        	current 
           DESCRIPTION
                   "Represents media- or physical-level addresses." 
           SYNTAX        	OCTET STRING
Changes to:
    PhysAddress ::= OCTET STRING 
    --      DISPLAY-HINT 	"lx:" 
    --      STATUS        	current 
    --      DESCRIPTION
    --               "Represents media- or physical-level addresses."