diff --git a/ImplementationDetails.md b/ImplementationDetails.md
new file mode 100644
index 0000000..823999a
--- /dev/null
+++ b/ImplementationDetails.md
@@ -0,0 +1,24 @@
+# Implementation Details
+
+Various common aspects of implementation are suggested and described below.
+
+## ETL
+
+Most likely it will be necessary to [[http://en.wikipedia.org/wiki/Extract,_transform,_load|ETL]] all available and relevant data from other systems.  This will need to happen on a regular basis (typically nightly) for as long as the integration with or migration from the other system(s) lasts.
+
+The ETL process will necessarily be quite custom for each organization, although it's possible that some common back-ends might be "supported" somewhat over time.  Most of the objects will require a custom "key" (mapped to the class via a [[http://packages.python.org/Rattail/extensions.html|Rattail extension]]) for the sake of tracking the object between ETL jobs.  For example, since our other system is CAM32, I'll map a field called `cam32_key` (with a unique constraint) to the Product class.  Prior to creating a new Product within Rattail during the ETL job, I'll first search Rattail for a Product which contains the `cam32_key` in question.  If found then that Product will be updated; if not then a new one is created and its `cam32_key` is assigned. 
+
+### Customers
+
+When ETLing *new* customer data, the transformation step could be somewhat heavier.  Since Rattail supports associating more than one Person with a Customer, and since most other systems probably assume a "Customer" *is* a single "Person", the process will be to:
+
+ 1. Create a Person.
+ 1. Attach contact info to the Person.
+ 1. Attach the Person to a new Customer.
+ 1. Assign the custom key on the Customer for object tracking.
+
+On the other hand, the other system might also have the notion that a Customer may include more than one Person, in which case the mapping should be more or less direct.
+
+### Prices
+
+The Price class will not need a custom key field, as its uniqueness may be determined by its `product`, `level`, and `amount` attributes.  When a price change for a previously-ETLed Product occurs between consecutive ETL jobs, the old "current" `Price.expires` is set to the current date, and a new Price is created with `expires` set to `None`, so as to make it current.