+1 to the advice above on a gradual migration via failovers or "strangler"
One method that once worked well for me in the past: viewing everything as a Service Oriented Architecture and extending the old system with new routes that enabled it to be the Auth/Login component for the new system. That let the old system act as-is with no change. When everything got migrated over to the new system, the auth endpoints were switched over to the new system too. An example flow: * User visits NEW page. NEW redirects to OLD for auth. * User logs in on OLD, which now has an auth callback info (e.g. oauth). * * OLD handles login and sets it's own cookies/session. * * OLD redirects to NEW auth-in endpoint * NEW sets it's own sessions/info based on the auth-in token and background data exchange. -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to pylons-discuss+unsubscr...@googlegroups.com. To post to this group, send email to pylons-discuss@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/pylons-discuss/cff20da8-82c4-473d-9c9b-d55026f7357c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
