Sooner or later a method built on one instrument has to run on another: a lab adds a second vendor, a protocol moves from a shared core to a satellite site, or a collaborator wants to reproduce your work on their own deck. The instinct is to treat the move as copying files across, and that instinct is what gets people into trouble. Some of what a liquid class encodes travels cleanly to the new instrument; some of it does not travel at all.
What translates
The intent of a class is portable. The liquid it is for, its family, the volume range, the dispense mode, and the general shape of the parameters, faster for water, slower for glycerol, more blowout for a sticky liquid, all carry meaning on any instrument. If you understand why a class is set the way it is, you can rebuild that intent anywhere.
What does not
The exact numbers usually do not. Flow rates depend on the fluidic path and the plunger; air gaps and blowout depend on tip geometry; level-detection settings depend on the sensing hardware, which may not even exist on the target instrument. A parameter named the same thing on two platforms can mean subtly different things, and a class tuned for an air cushion does not map onto a system-liquid path. Copying the raw values is how you get confident-looking numbers that are quietly wrong.
A plan for the move
- Capture the intent, not just the values: the liquid, family, volumes, dispense mode, and why each parameter was chosen.
- Map the vocabulary, since the same behavior hides under different parameter names on each vendor.
- Rebuild from the closest predefined class on the target instrument, using the source class as the specification of what good looks like.
- Re-validate on the target hardware, because a ported class is a new class until you have measured it.
A method does not port; its intent does. Carry the reasoning across vendors and re-tune the numbers, rather than copying values that assumed different hardware.