diff --git a/README.textile b/README.textile
index bac165e94..7155a7c75 100644
--- a/README.textile
+++ b/README.textile
@@ -58,4 +58,8 @@ class CreatePosts < ActiveRecord::Migration
 end
 </code></pre>
 
-Note that the ActiveRecord model @Post@ must already exist and have a @translates@ directive listing the translated fields.
\ No newline at end of file
+Note that the ActiveRecord model @Post@ must already exist and have a @translates@ directive listing the translated fields.
+
+h2. Migration from Globalize
+
+See this script by Tomasz Stachewicz: http://gist.github.com/120867
diff --git a/notes.textile b/notes.textile
deleted file mode 100644
index 8662fc45d..000000000
--- a/notes.textile
+++ /dev/null
@@ -1,61 +0,0 @@
-virtual locale attribute for translated records:
-
-Post.create(:title => 'Titel', :locale => :de)
-
-maybe allow to set the locale attribute name for separating display and content locales.
-
-
-
-------------------------------------------------------------------------------
-
-Stopped DB Backend in the middle, here's where we left off:
-
-h1. Some Notes
-
-* Started doing the migration generator in generators/db_backend.rb
-* Translation keys will be in dotted string format
-* Question: Do we need a plural_key column, or can we build it in to the dotted key?
-* We will probably have to code the following methods from scratch, to optimize db calls:
-** translate
-** localize
-** pluralize
-* We should refactor @interpolation@ code so that it can be included into backend code without inheriting SimpleBackend
-** Rationale: interpolation is something done entirely after a string is fetched from the data store
-** Alternately, it could be done from within the I18n module
-
-h1. Schema
-
-There will be two db tables.
-
-# globalize_translations will have: locale, key, translation, created_at, updated_at.
-# globalize_translations_map will have: key, translation_id.
-
-globalize_translations_map will let us easily fetch entire sub-trees of namespaces.
-However, this table may not be necessary, as it may be feasible to just use key LIKE "some.namespace.%".
-
-h1. Caching
-
-We'll almost certainly want to implement caching in the backend. Should probably be a customized
-implementation based on the Rails caching mechanism, to support memcached, etc.
-
-h1. Queries
-
-We'll want to pull in lots of stuff at once and return a single translation based on some
-quick Ruby selection. The query will look something like this:
-
-<pre>
-<code>
-SELECT * FROM globalize_translations
-WHERE locale in (<fallbacks>) AND
-key IN (key, default_key)
-</code>
-</pre>
-
-The Ruby code would then pick the first translation that satisfies a fallback, in fallback order.
-Of course, the records with the supplied key would take precedence of those with the default key.
-
-h1. Misc
-
-We should revisit the :zero plural code. On the one hand it's certainly useful for
-many apps in many languages. On the other hand it's not mentioned in CLDR, and not a real
-concept in language pluralization. Right now, I'm feeling it's still a good idea to keep it in.