I'm in the midst of converting a semi-complete Django application to deploy on Google Apps Engine. It's not going as smoothly as I'd like, to say the least. After the jump, my first thoughts on the subject and a couple gotchas I ran into.

If you haven't completed your application, don't write it for Django. GAE-Django is a completely different beast.

There's a couple obstacles you'll face immediately:

1. Models and queries have to be rewritten for BigTable (the google db backend). Yes, this is probably 25%-50% of any simple CRUD application (well, it's 25% to 50% of mine!) BigTable doesn't just use different field types and query syntax, (all() instead of objects, order instead of order_by), but takes a different approach to storing data. If you've worked with relational dbs, you've had it drilled into your head that data should ALWAYS be normalized, and only denormalized in extreme situations, where you're able to prove a performance benefit (and only in cases where denormalization is cheaper than RAM). GAE limits the types of queries you can make, so in some instances you MUST build in redundancy simply to retrieve information as you normally would. For example, as my application works with date ranges, so I now have start_date (a DateTimeProperty), end_date (also a DateTimeProperty) AND start_date_category (a DateProperty) so I can grab all records with a particular date rather than searching for all records in between start_date and end_date. Now, I may be doing this incorrectly, but I've yet to see a documented alternative. Since I have 'unlimited' power, and GAE is free up to an extremely reasonable point, I don't really 'care', but if I ever want to port *away* from Google, I'm going to be doing a lot of work. What I plan on doing is creating an interface that will allow me to encapsulate all the "GAE hacks" so that if I do need to port the number of files I will have to touch will be minimal. I've been wanting to experiment with SOA, so this is probably a great place to do it -- hopefully I can keep the data sorting and querying to just a few functions. I'm not clear yet on whether I can use class properties in queries, if I can, then this is probably really easy to get around. Would love to hear other opinions on this.
2. It is not simple to set up the Django trunk. Even though it is supposedly possible, I did not find there was sufficient documentation to make this a simple process. Since I had to rewrite all my models anyways -- and that's where I was using the .97 features -- I wasn't too bothered, and this problem will probably be fixed by this Fall when 1.0 comes out, but again, another good reason to write TO GAE if you have that option, instead of writing a django app and then porting it.
3. The google django helper app sends print statements to the web rather than the server process -- this may not affect you, but if you were using "print" statements for quick-n-dirty debugging, you're going to have to go through and remove all of them to get a properly rendered page.
4. It's probably not worth writing it in Google's webapp framework, since you're probably going to use Django templates anyways. Might as well write a hybrid GAE-Django app and then rewrite if you choose to port off of GAE, rather than writing a GAE-only app that may be difficult to move. Again, would love to hear other opinions on this.